Month: March 2020

Fourth Sprint – Gungnir Finalization, Stalwart Tuning

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.

Second & Third Sprints – Tuning and Breaking

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:

View post on

You may need to click the link to see it in action.

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.

View post on

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:

View post on

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

View post on

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!

Theme: Overlay by Kaira
Ann Arbor, MI