Fourth Sprint - Gungnir Finalization, Stalwart Tuning

The last three weeks have been pretty tumultuous for everyone, I think - naturally, this has affected the progress of Project Blue significantly. Over these last three weeks, I have finalized the Gungnir enemy's behavior and worked on tuning the Stalwart, the charging enemy I discussed in my first blog post.

The Gungnir

For this sprint, I finished tuning the Gungnir's jump scaling, and I tested it a bit more seriously in a test level and made some recommendation about how I believed it would be best to move forward with the Gungnir.

Previously, the Gungnir's jump scaling was not great. It only scaled relative to how high the player was after a short period of time after the gungnir detected it was above a certain height above the Gungnir... If you can follow that sentence, awesome, because I can't. It did not work particularly well - it would scale the same if that player had just jumped from slightly above the gungnir, or if they had just reached the peak of their jump, and the way I did the math to scale it meant the scale factor was often unnoticeable. Here is how it looked at the time of the last blog post:

Since then, I have changed it significantly. It still detects when the player is a certain height over the Gungnir, but rather than waiting an arbitrary period of time and jumping with an arbitrary force, the Gungnir instead waits for the player's y-velocity to equal 0 before jumping exactly up to the height that player is at, calculating jump force each jump. Additionally, the Gungnir does not jump at all if the player is falling. This looks and feels much better than the original setup.

It isn't perfect - if it's only shooting at the peak, and isn't jumping until the player reaches their own peak, then the Gungnir is guaranteed to miss just about 100% of the time, if the player were to only jump once. The Gungnir should be able to force the player to keep jumping, though, so I think this is an issue that sort of solves itself. I did increase the projectile speed to make up for it, but I do not believe it would be an issue. Further testing would be required to be sure, but it's a moot point, as the Gungnir has been cut moving forward.

Even so, I did think about where it should go in levels, so here are some examples

Both of the above areas are asking the player to make one good jump that has consequences on a failure - these jumps are both relatively easy, so the gungnir adds some extra challenge to mix things up a bit.

Here, the gungnir seeks to mess with the player's vertical movement instead. Same concept as above.

Here, it simply requires the player to use a little thought when approaching a fairly straightforward section of the level that is otherwise totally unthreatening.

The Stalwart

My other task was to improve and tune the Stalwart. With this, I had quite a bit I needed to do. Not only did it need tuning, but after some discussion with leads, we decided that the Stalwart's originally planned charging style, where it barrels at the player until it hits something and can break blocks, would be better than having it just run towards the player indefinitely. I needed to implement that. It also had no warmup to its charge, so I needed to implement a brief wait period before it charges at the player so that it would not appear out of the blue and kill the player.

The first thing I did was implement the warning. I figured this was most likely going to be done with animation rather than code, so I added a brief wait period. I also tried to make it hop, but this caused some weird bugs that did not seem worth dealing with:

*The Stalwart's art is not in the project yet, so I used the Twitter/Discord avocado emoji.

Then I dealt with having it charge until it hits something. While this seemed simple at first, it wound up being a large portion of my time. Originally, it would charge towards the player, and if the player jumped over it, it would slow down to a stop and then charge in their direction again. This certainly has the potential to be interesting at times, but it ultimately seems like it would be more annoying than fun:

Charging until it hits something I think has better implications for platforming gameplay and level design:

This image depicts a possible section of a level where a Stalwart is baited through a basic platforming challenge before destroying a crystal wall, which the player can not break on their own.

Here, the player will drop into this hallway and become trapped with the Stalwart, and they must dodge it multiple times to continue, lest the avocado turn them into guacamole.

Here, the player pops up from the walljump challenge below and is greeted by a charging surprise of monounsaturated death.

Here, the player drops down from above and must avoid getting creamed by the Stalwart as they land.

Here, the stalwart will run back and forth forever until the player either leaves this small pit area or kills it. This means that the Stalwart can still be used as a combat-focused enemy. While the player could easily escape in this situation, situations could be created where the player must eviscerate the stonefruit in order to continue on.

In these sorts of situations, the Stalwart excels as something that can just throw itself at the player and attempt to get in their way. If there's a breakable block at the end of the segment that the player needs the stalwart alive to break, then now these segments can become puzzles about how best to get the Stalwart down to the block without killing itself or the player.

Making the stalwart charge at the player was easy enough, I just had to make it so that the Stalwart not turn around. However, it would still stop when it got too far away from the player, defeating the purpose. This took some time to fix, but the code was straightforward enough. The biggest problem was when the stalwart would crash into walls:

This bug took a while for me to fix - ultimately, raycasting was the solution, but having never worked with 2D raycasts in Unity before, I was shocked to find that they're structured almost nothing like 3D raycasts! *grumble grumble*

But, it works now! At first, it looked like this:

*pinball sounds*

But eventually I got it working as intended:

Then, after that, I just had to implement the breakable block:

This requires that the block be on the Terrain layer, which is unfortunate, and the feature is not technically complete, as my intent is that this kills the Stalwart, but health is not yet complete as far as I know. This should be a simple fix, though.

Thankfully, the Stalwart has not been cut. Further testing will be required to perfectly nail down values - it was extremely fast at first and I've toned that down, but it may need to be toned more. Damage and health will also need to be tested once implemented, and we may decide was want to go back to charging towards the player anyway.