Category: Project Blue

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!

Project Blue – First Sprint, Enemy Design Conceptualization

Project Blue – First Sprint, Enemy Design Conceptualization

Hello all! I’m back, and this time I’m designing enemies for WolverineSoft’s new game, currently codenamed Project Blue. Over the last couple of weeks, we started production! In our first sprint, my role as a designer meant I was designing enemies for our first area, the Crystal Caves. I conceptualized three enemies: “Qrabz,” “Stalwart,” and “Cube.” In this post, I’m going to go over these designs, and discuss the merits of each design, as well as some of the weaknesses. As it stands, none of these enemies have been prototyped or had concept art completed for them, so there is little I can share.



The Qrabz starts out as a basic enemy that serves as little more than a jumping and attacking tutorial – it patrols until it sees the player, then rushes them down. The player simply needs to either jump over it and ignore it or to quickly dispatch it with a sword swing or two. As the game goes on, though, the Qrabz evolves with the player. Drawing inspiration from hermit crabs, a Qrabz can take the crystals of the environment, using them as a shell that covers a certain portion of their body. However, a Qrabz will usually have a part of their body uncovered by armor. This means that the player must attack that area of the Qrabz in order to stand a reasonable shot at victory. The Qrabz can also hold a large crystal shield, which can deflect attacks or even deflect the player’s teleport ability, and can be repositioned to face the player. On top of all of that, they can be any size, with health & speed corresponding to their size, which means that a Qrabz can be a small platforming obstacle, a harrier enemy, or even a mini-boss. Due to their environment, they could also hide in the background and ambush the player, like a Bokoblin in Wind Waker hides in a pot. The initial design concept had a charging claw as well, but that is fairly redundant with the existence of the Stalwart, which will be discussed later.


There are a lot of these, in a bunch of categories. Most of these pros stem from the relative simplicity and flexibility of a Qrabz. Thanks to their basic behavioral patterns, a Qrabz is a good enemy to slot in just about anywhere. Presumably, this will be one of the first, if not the first enemy encountered in the game, and from then on the player knows pretty much exactly how they’ll act. As the game goes on, a larger Qrabz or an armored Qrabz will pose a higher difficulty and more interesting challenge, but the gulf of evaluation will remain narrow. The only time a Qrabz’s behavior will change will be whenever the crystal shield is introduced. The shield should add an interesting mixup that does involve a slight behavioral change, but the Qrabz will still move and act the same – now, though, it has a way to protect its weak points from a player who hesitates.

These positives extend into production. Level designers can just drag and drop a Qrabz into a level. If they want it to be a challenge, then they can drag and drop some armor pieces onto the Qrabz, or they can scale it up. For artists, the Qrabz is a flexible enemy that only needs one main sprite and then additional sprites that can be placed on top of it, rather than a new sprite for each variant. The Qrabz can also be placed in any future world with slight sprite changes and, if desired, behavioral changes. As an example, a Windmill Fort Qrabz could have steel for its armor and could walk on walls.


If we overuse the Qrabz, it could become quite dull for the players to see the same enemy popping up over and over again. I also am worried that an armored Qrabz may end up being seen as an un-fun nuisance, but that will require fine-tuning to avoid, I think.

The Qrabz has been chosen to be included in the game, which has me really excited.



I was told that other members of the team were interested in a charging enemy. At that point, I had already finished the Qrabz concept, which included a charging claw, but I thought that the charging claw on the Qrabz was going to be weird, hard for a player to catch, and would lead to too many behavioral changes, so I agreed that we would want a dedicated charging enemy.

Thus, the Stalwart was born. The stalwart is a larger, tougher enemy that, when aggro’d, charges at the player endlessly. Once it starts a charge, it runs until it hits something solid – even off of platforms or cliffs. Charging is the only way it moves while it is aggro’d by the player. Its charges are highly telegraphed, giving the player plenty of time to react and get out of the way. If the player strikes a charging stalwart in the head, the stalwart stops its charge, but if the player gets hit by the stalwart, they take significant damage. The key thing here, though, is that a stalwart’s charge can break through certain surfaces and objects that the player can’t, such as collapsed walls, opening up new routes. Its charge can also kill other enemies.

Initially, the design had two other behaviors – one where it only charges to the end of a platform, and one where it charges until x-aligned with the player. I think the others are interesting, but not worth the effort of implementation.


The stalwart’s charge turns this beast into both one of the biggest threats likely to be in the game (bosses notwithstanding) while also serving as an extremely valuable puzzle-platforming tool for the player. Getting hit by a stalwart will be suitably punishing, but the aha moment of baiting a stalwart towards a cliff to kill itself, getting it to kill a hoard of enemies, or tricking it into opening a blocked tunnel will make the risk more than worth it.


I think baiting a stalwart around could get boring if overused, and will require great care to make each puzzle feel right. My other concerns with the enemy stem from simply not totally knowing how the game feels – I don’t know how often a stalwart can work as an enemy you have to fight rather than an obstacle or a tool.

The Stalwart has also been chosen to be included in the game, which I am also extremely excited about. I think the Qrabz is a highly useful and practical enemy, and will hold a lot of importance, but I think that the Stalwart will be a far more interesting enemy to play with.



To be totally honest, the cube started out as a whim. I wanted to design an enemy that existed solely to punish bad sword throws. The Cube is almost what I got. An enemy that, when a thrown sword touches it, it swallows the sword and holds onto for a sec. If the player teleports to a swallowed sword, they, too, are swallowed, and take damage until they mash out. The Cube never moves and has no real aggressive behavior whatsoever, and can not be killed by most means. Wooo!

Thankfully, I decided that wasn’t enough. The Cube can also swallow enemies that touch it, and it can only swallow one thing at a time. But what happens if a second thing (enemy, sword, or player) touches it while it’s swallowed something else? They bounce! Hard! The cube would bounce whatever touches it a large distance – farther than the player could normally go with a normal sword throw. This turns the cube from a rather boring obstacle that would probably only be annoying into an excellent platforming hazard that should fit neatly with other mechanics and enemies in the game. Once you bounce off of a bouncy cube, it ejects whatever it’s swallowed and becomes a regular hungry cube again.


The Cube is a powerful tool, I think. Bouncing is always fun, and I can see a lot of particularly fun moments in mixing bouncing with other mechanics, or with more bouncing. A platforming challenge requiring the player to bounce from cube to cube, which requires the player to bounce, then throw the sword at the next cube, bounce off that, etc. could be fun. I could also see a fun challenge in something like getting a stalwart across a gap – I think that cubes and stalwarts are a particularly interesting combo that could make for some really cool puzzles.


I honestly don’t think a cube would ever be fun when used as a punishment tool. There might be some situations where it could be neat, but I think it would make for an arbitrary roadblock rather than a real interesting challenge. Other than that…. they just aren’t really enemies. They’re cool level design implements, but that’s really about it, I think.

The cube was not chosen to be included… yet. I think it would definitely be a better fit for the highly-vertical Windmill Fort, and I think I could do some revision on the design concept before it might be ready to be accepted. However, I think it has an extremely high fun ceiling, and hope that it will be included in the future.

For this sprint, I think I came up with some great enemy designs, and I’m very much satisfied with what I’ve got. I think I could have maybe come up with one or two more interesting designs, but I think these designs are a great starting place for an opening area, and I think the Qrabz and Stalwart are essentials. Stay tuned for two weeks from now, when I’ll post another update. By then, the Qrabz and Stalwart should have much more to them, and we may be moving onto the Windmill Fort’s designs.

Theme: Overlay by Kaira
Ann Arbor, MI