Second & Third Sprints - Tuning and Breaking

While my first sprint was light, these two started out a little lighter. As my role is primarily that of a designer, I was bottlenecked by programming and art, and there were not enough programming tasks for me to pick up more. The first sprint of these last two weeks, my only task was to create some prefabs, which went painlessly.

This week, I had some more interesting tasks. I was directed to fine-tune the gungnir enemy, and I also found some extra programming work within the level design pod creating breakable blocks.

The Gungnir

The Gungnir is a basic enemy that shoots projectiles at the player, and can jump up and down in-place to try and hit a player who's jumping. Here is what the Gungnir looked like when I got to it:

It fires at a decent pace, but the projectile is slow and its jump response is a little laggy. At first, I tried speeding the projectile and fire rate, and making the jump more responsive. I also made it so that it is a little less likely to jump in response to the player jumping, as it would jump when the player made even the tiniest hop before.

While this seemed good at first, when I tried to put the Gungnir into the demo level, it became clear to me that I needed to do some more. The large range over which it can shoot at any time can sometimes feel oppressive, and the high fire rate makes it hard to platform around. Additionally, especially in a platforming environment, I thought it felt weird that the gungnir could shoot at any point in its jump - not only did this mean that it could cover the entire vertical spectrum with its shooting, but also that it would sometimes perform "empty" hops - hops where it would never shoot. This meant I needed to make some changes to its AI.

First, I wanted to see if I could make it shoot only at the top of its hop. This would, on paper, give it more predictability and clarity, while also limiting its fire rate a little bit. This is the outcome:

While it isn't perfrect, I think this looks quite clean when compared to before:

Now, it looks clean... but I am unsure whether or not I think it's better for gameplay. As it is, I have made peak-only shooting an option that I was going to disable and leave for later, but I implemented another feature that I think works nicely with it. Now, the gungnir's jump scales with how high the player jumps. Before, if the player performed a shorter hop, the gungnir might jump to try and shoot them. However, the gungnir might have jumped twice as high as the player - it seemed weird. Now, it scales to the player's jump height:

This effect is admittedly rather subtle as it is, but I am still going through the process of tuning it. As it is, it takes a scalar created by dividing the height differential between the player and gungnir at the time of the jump, then dividing that by the buffer used to determine whether or not to jump, and finally doing some totally arbitrary math to make it feel reasonable. I think I've made great progress on this so far, but still have a bit more to do. Obviously, I have done nothing with damage (both dealing and receiving), but that has yet to be set up, and I'm not yet satisfied with the way jumping works quite yet. Empty hops are still possible, and I want to avoid messing with weapon cooldowns in the same way I've messed with jump height. The jump height still is not perfect, and I may look into combining the current height detection method with reading the player's jump input - using inputs would allow the gungnir to more accurately scale its jump to the player's, but maintaining height reading allows the gungnir to jump even when the player is not actively jumping but is instead simply above the gungnir.

Breakable Blocks

This is a much smaller section. There was no extra work for me within the enemies pod beyond tuning the gungnir, but I did find an extra programming task within the level design pod: implementing breakable blocks. This task seemed right up my alley - not only was it a good and interesting task, but with the Stalwart design (a charging, block-breaking enemy) I mentioned in my last post, it also related to my own work within enemy design.

This was a fairly easy implementation: following Brackey's tutorial on breakable objects, I created an object that can be broken into smaller pieces when hit with the player's sword. The number of hits required to break the block is adjustable, and the script should be applicable to any breakable object.

Here is the outcome:

Ultimately, I'm happy with how this turned out. The smaller pieces only collide with the environment - an earlier version would have allowed the player to platform off of them. And just to show how well it works out with other shapes:

Very happy with this result - I think it looks great and is quite juicy. Physics are applied to each child of the broken object individually, so it works with any number of objects post-break:

Overall, pretty happy with my work this week. I still have a bit of tuning to do on the Gungnir, but I am pleased with my progress. For future sprints, design should be less bottlenecked by programming, so I'm excited to start to test and tune more of our enemies!