Skip to main content

KEIS Sprint 4

  This sprint, I worked on some upgrades to the heavy enemy, some touch-ups to the wave system, as well as ensuring that the player will always see the tutorial once before they first play the game.


Starting off with the heavy enemy, feedback indicated that it felt too similar to the medium enemy. They were essentially the exact same, except one was bigger and shot more rapidly. In order to further differentiate the two, we decided to give the enemy a burst-shot, as well as a unique ground slam ability that would hinder the player for getting too close.



For the burst fire, I decided to use a delay loop that would retrigger until int Burst Index reached 0, decrementing it at the end of each loop. At the end of the loop, an event is called that notifies the AI controller that the burst fire sequence is complete.


I think that in the future, it might be better to take another stab at this using a timer handle, and probably some more descriptive function names than “FireProjectile” and “Shoot”. In this case, FireProjectile is the function that starts the burst fire sequence, while Shoot is the function that actually spawns the projectile and assigns it a velocity.



Within the Shoot function, I’m finding the vector that points from the current actor’s firing point to the target vector input. Then, I spawn a projectile, assign it a rotation, and after a validity check, assign it a damage value based on the enemy’s stats within the data table.



With all this set up, I had the burst fire working exactly as intended! I could easily modify the amount of shots, as well as the delay between them.



The second thing I want to share from this sprint is the Heavy Enemy’s ground slam ability. When the player gets close to the Heavy, we want it to slam the ground and create an area on the floor where the player will take damage and have their movement hindered.



My approach here is again not the best I feel, I was aiming to just get something working quickly so I could start testing the slam ability. I’m tracking the cooldown of the slam using a timer this time as well as a boolean (so that the Behavior Tree can look at this bool and know if the slam can be used or not). When the slam event is called, I’m spawning an actor, delaying for 1 second to stop the Heavy from acting again immediately after the slam, and then notifying the behavior tree that it can act again.



For the slam itself, I’m spawning a big cylinder on the ground that will damage the player. To ensure that the player isn’t taking continuous damage, I have a boolean that tracks if the player has already taken damage from this slam instance. We also want the slam to hinder the player’s movement, but that will require some cooperation between me and my co-programmer who has done all the work for the player controller, including the speed, dash, and other movement abilities. I haven’t had the chance to work with them during this sprint, and so I’m going to do that first thing next sprint.


This is what the slam currently looks like!


Right now the slam doesn’t really feel much like a slam, with just a red circle appearing on the floor when you get close to the Heavy. Without animations, the easiest option available to me to better communicate the idea of a “slam” is through VFX, which is the last major thing I worked on this sprint.



My idea for this effect is that this ring will expand from the heavy enemy until it shows the full radius of the ability, acting as a warning before the slam is actually triggered. After the ring has reached its full size, I want to repurpose some of the alpha’s I made for the muzzle flash in order to create an impact effect, like the ground is being struck. At that exact same moment is when I’ll spawn the slam ability. So far I’ve only been able to get the ring part working (By creating a decal material consisting of a sphere mask subtracted by another, smaller sphere mask). But I intend to implement the rest of this idea in the upcoming sprint.


Comments

Popular posts from this blog

CAGD 373 Blog Post 4

This sprint I was assigned a modular set to create the basic interior rooms out of, with three different textures for the walls. (a Square Brick Texture, a Cement Texture, and a Metal Wall Texture) The actual modeling itself was as basic as it gets, I just made a few different shapes and sizes of wall along with a doorframe, with a couple floors and ceilings to complete the set. The interesting stuff this week was the textures, all of which I made in designer! The brick texture was probably the most complicated, and the one I’m most proud of. Starting with a brick generator, I used some gaussian spots to add some variance to the shape of bricks (using the spots to “cut out” chunks of the perfectly square bricks) and that worked pretty well! After that, I used a grainy looking noise map to fill in the black part of this mask to add in the noisy texture of mortar between bricks Next, to add some color variation to the bricks, I used a flood fill node, which was able to identify all the...

Idle WitchCraft Sprint 4

  This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line. Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm! This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate inf...

CAGD 370 Blog Post 5 - Final Sprint and Postmortem

  The Final Prototype is officially done! And this final sprint has definitely been the most intense yet. While not perfect, I’m very happy with the game that me and my team have made, and I feel a lot of motivation to start a brand new project! But before I get ahead of myself, it’s a great time to reflect on the last two weeks and this project as a whole. To start off our final sprint, I once again made adjustments to the pole vaulting. I made the impulse of the vault scale with how close you got to the pole, which meant that not only could the player not get an immense movement boost from a standstill, but also that there was now a “sweet spot” to aim for to get the most vertical height out of the vault. To help players seek out this sweet spot, I also took the time to create a charge-indicating progress bar next to the player that would fill up the closer they got to the sweet spot. The bar progressively fills as the player approaches the sweet spot After this, my lead de...