Fifth Post - Beta Work - Level Design, Controls Updates, Player Feel
This weekend, we finally hit beta. I had some role changes throughout the last couple of weeks, moving from enemies to level design for the third Crystal Caves stage, and then to updating the keyboard controls, and finally player feel.
Crystal Caves - Stage 3 (6 Hours)
Working on this stage was interesting. I was to pick up work on the creative director Alex Kisil's WIP stage and finish it. This is how the stage looked when I got it:
The player spawns in at the red arrow, and must work their way to the bottom right.
The level was initially designed to be a branching path, and then was reworked to be linear but appear to branch. There's still a lot to do on it - there are no enemies on this version of the level, and the difficulty of platforming is too variable. Some platforming challenges seem a little too simple, while others are nearly impossible.
The first thing I did with this level was simply set it up to work like other stages in the game - each stage is a prefab set up in a specific way, so I needed to set it up to work as a prefab, which took a fair bit of time due to my total lack of experience designing levels. Once I got that figured out, I set to work testing the level to see exactly what I should change and what should go where. Before I could really get to work implementing most of these, I was pulled away to work on other, higher-priority tasks, but I will share my ideas here:
Intro Section - Stalactites & Spikes
This introductory section seemed a little too easy to me. For the final level of this stage, I felt that a long section of jumping to the left was unnecessary. I figured this would work best like this:
Mostly minimal changes, but with some enemies thrown in. The first set of spikes would be raised, and the stalwart would be able to charge at the player through the spikes. This would force the player to be careful both approaching the spikes and in their landing, and they could potentially deal with the stalwart by dropping the stalactite on it. The acrobat is meant to make a tighter section of the area even tighter, as the acrobat leaps through the air at the player and applies pressure. Both qrabz are mostly meant to force the player to pay a little more attention.
Spike Pit
This long crystal drop section afterwards, in my opinion, is probably a little too long of a pit to throw the player down without showing them what's below. I would prefer this section to require the player to slide down the wall while jumping back and forth between walls, like so:
This is more active and will slow the player's descent, but should still be difficult.
The Monocle'd Ghost
This section, which I think looks like a ghost with a monocle, just seems to be lacking in interesting elements. I think all it needs is some enemies, specifically Acrobats, jumping around.
The Pelvis
This section definitely needs to have something going on - but what?
The green trail is the player's, and the orange is the stalwart's.
I thought this would be interesting. The first jump should be more challenging, and would likely have required a lot of tuning to get right, but I'm a huge fan of jumps that require the user to slide down a wall and then wall jump. The Stalwart is meant to be a sort of nasty surprise for an inattentive player, and it should be able to run across the spikes and hit the player.
The Wide Room
This room is wide open and lacks much reason to do anything but go straight to the right. However, I think it's a very interesting room for a number of enemies, with minor layout changes:
The top couple of platforms are rearranged to allow a Stalwart, which sees the player and charges at them towards a breakable wall that only a Stalwart can break, but not the player. This means the player MUST provoke the stalwart, and the level would require something to point them in that direction. The other enemies, 2 qrabz and an acrobat, as well as the ceiling spikes, are here to make the player's task of dodging the stalwart more interesting.
The Geodude
This Geodude-shaped section also features little challenge. Here is my thought:
Several acrobats should make these rooms more interesting. Spikes on the some parts of the ground make avoiding the ground important, but Acrobats mean the player can't stand still for long. The top left platform has been made narrower so that the stalactite can fall to the ground, giving the player and extra place to stand. The stalwart after the bottom is simply meant to catch the player off-guard and chase them through the small area, which is followed by a quick break-y area.
The Gizzard
To be totally straightforward, I don't really know what to do with this room besides making the tiny platforms larger. It's extremely difficult. I just wanted to address this in some capacity, but I don't yet have a solution.
The Big Pit
Another pit. This one isn't particularly exciting, either, but has a couple of frustrating elements. This pit is extremely deep and extremely wide, and the player can't wall-jump across it. If you miss breaking the breakable wall in the middle of it, you still have to fall an additional second or so, unrecoverably, before you die. And if you do break the wall, there are spikes hidden inside of it that prevent you from landing. Here are my changes:
I wanted to highlight the wall here.
I made the pit considerably narrower and shallower, most notably. If you miss the breakable wall, it still shouldn't be easy to recover, but it's not impossible, and the player will no longer be scrambling to rescue themselves when there's no way they can. I got rid of the spikes inside the wall, as that just seems unfair. At the top of the pit, the player should be able to slow their descent while wall jumping and sliding.
I had considered including a stalwart across the pit that the player needed to bait out and then walljump stall while waiting, but that seemed like it was a bit much.
The ::O
I really like the base design of this section. As I said earlier, I like sections involving interesting walljump trajectories. However, this section was harder to actually perform interesting walljump maneuvers with. I expected this:
But it came out a bit more like:
My changes would push the player more towards the initial style:
Subtle positional changes for the platforms as well as changing some spikes should make the player a bit more likely to be able to perform the maneuver I was expecting, while also allowing the player to potentially take a different route as well.
As I mentioned before, I was not able to actually implement any of these changes before I was grabbed for something else, but I do have a good direction to take things when I return to this task.
Keyboard Controls (2 hours)
While I was working on level design, I was pulled to improve our keyboard controls. This proved to be fairly straightforward, and did not take me too long. I was asked to compare Project Blue's keyboard controls with other, popular platformers such as Celeste, Super Meat Boy, etc. This was a very tough task, I must say. I decided to compare controls with Celeste and Shadow Complex. Celeste was... shocking, to say the least. I wouldn't wish Celeste with a mouse and keyboard on my worst enemy. Shadow Complex was much more manageable, and... its controls were surprisingly close to ours. I noted that its default controls tended to favor the index finger other than for pressing tab and shift, so I moved in that direction as well.
After seeing how another game controlled so well, I felt confident making only minor changes to our control layout. I made the following changes:
'E' Key: E is bound to Throw Sword/Teleport now. It is also bound to Right Click, but in case players do not have a right-click function (that is, are playing on a macbook with only the touchpad), I thought it needed a keyboard binding as well.
'F' Key: F is now bound to Cancel, which returns your sword to you without teleporting. This used to be bound to 'Q', but I thought it made me sense to have it near the throw button and to be on the index finger.
'Q' Key: Is now Interact, which will likely not be used.
That's really it. With some testing, people seemed to appreciate the new control scheme.
Player Feel Iteration (9 hours)
After that, I was given another large and fairly open-ended task: making the player feel better to control. This task is naturally fairly vague, so I spent some time talking it over with the player pod lead, Matt. We came up with this list of tasks:
Increasing throw projectile velocity/range
Teleporting granting a small amount of momentum to the player
Decrease player size
Increased wall slide speed and add acceleration
Have time dilate in and out of the slowmo mode rather than an instant change
Increase attack range
Have the player's air velocity gradually slow to 0 rather than instantly stop
Increase/decrease slow-mo factor (decided against doing this)
At our most recent playtest session, we got a lot of feedback that the attack range was too short, so we made that our highest priority. After that, we thought I should increase the projectile throw velocity/range, as those two tasks go hand-in-hand - increasing the velocity increases the range. Then, I would decrease Io's size, which inherently increases the size of the world and the enemies without requiring level design changes. These tasks were not going to require code changes and all addressed common complaints, so they came first. After that, I would implement teleportation momentum, which would require code changes, and anything else I felt was necessary.
Naturally, the first thing I did then was implement time dilation.
Really, I just started working on that one because it's code I've written before in another project and we hadn't started talking priorities. I knew how to do it and I knew it would feel good, so this was a pretty quick thing to implement, and I felt it would be a good way to familiarize myself with the character controller. Here is the result:
It's a subtle effect, but it's not as jarring as a sudden change:
The difference is not easily visible, but it is easy to feel when playing.
After that, I moved on to our actual priority list.
The first three tasks were all straightforward:
Increased Io's attack range from 2 to 2.75
To make this look okay, I also increased the size of Io's sword by about 30%.
Decreased Io's size from .7 to .65:
It's subtle, but it feels good.
Increased sword throw velocity from 18 to 25:
The range is slightly longer, and the sword reached the reticle much faster.
After that, I implemented the sword throw momentum. This required more code changes, but nothing too difficult. Tuning it to get it right, however, proved a challenge. I also introduced (and later fixed) some bugs, but I will touch on those later.
The goal with this feature was to improve the impact of teleporting on the game's flow. While this was not the most-reported issue by far, I personally found it extremely jarring how much of a hard stop the game's main mechanic put on gameplay. Some players found themselves avoiding teleporting because it didn't feel great, myself included. So the first step I wanted to take to improve this was to grant the player some momentum from their teleport.
Here is a comparison of the effects:
The momentum makes it way juicier without having a huge impact on gameplay. One concern we had was that the momentum would make platforming challenges harder, too, but I actually found the opposite to be true in my personal playtests; if anything, it makes the game easier. The effect is so small that if you would have landed on something, but overshoot because of the momentum, it's easy to correct for. However, if you make an unexpected mistake and fall a little short of your goal, the momentum serves as a tiny boost that I found to save me from certain death surprisingly often!
However, momentum wasn't enough - and a bug caused by the momentum implementation actually pointed me in the right direction. The teleport function is called when the player hits spikes, and because the player wasn't teleporting to a sword when they hit spikes, it caused errors that broke player movement. My investigations into this bug led me to a problem in Io's Throw animation, where I saw that the sword wasn't being thrown until Frame 8. I moved it to frame 4. Here is the difference:
This is another hard difference to spot, but it's not hard to feel. I may actually further move it to frame 3 or even 2 in the future, as the only reason I had it on frame 4 was because the animation was set to loop, which meant if my computer lagged, having it too early would create multiple swords:
This actually still happened on frame 4, I just wasn't willing to have it higher than 4 frames.
This also showcases another thing I tried: When you throw the sword, rather than immediately stopping midair, the your velocity would smoothly shrink to 0. This felt... smudgy, would be the best way to put it. It felt like it was removing control from the player and smearing the player's velocity all over the place, so I decided not to move forward with it. I did get this funny bug from it, though:
This just left the wall slide acceleration change. This change was surprisingly difficult - I thought I could just increase wall slide velocity in a coroutine, but that just did not want to work for a while. Or, at least, I think it didn't - the way I realized this worked, after spending over an hour on it, was that I dialed my test values up significantly, and it suddenly worked. So lesson learned: Make sure that your test values aren't just too subtle. Here's the before/after:
This feature stemmed mostly from a personal gripe, but I think it's definitely going to benefit gameplay, as there are a number of sections that involve sliding down a wall and jumping from wall to wall.
Unfortunately, a not insignificant amount of time was lost to a random Wwise bug caused by git screwing up a merge. Thankfully, this occurred early on, after I had implemented the first three high-priority changes and time dilation only. I also had written down every value change I had made on a sheet of paper next to me, so once we decided I needed to nuke the branch, I was able to go in and just copy + paste all of my changes over. So that's another valuable lesson: record all of your changes outside of Unity, and push early & often.
What's Next
I believe that going forward, my level is going to be axed. While I was looking forward to working on it, I'm not sure that level design is my forte, and even though it would be an opportunity to grow, we're going Gold in 2 weeks, and there's still enough to do on that player that I'm okay with not finishing the level.
As for the player, a few things will be happening in the next couple of weeks:
Playtesting! I have a build ready to ship out to a few other members of the team.
Numbers will be tuned further. I've already been approached about further increasing the attack range, which will go alongside larger VFX (which was the reason I didn't make it larger anyway), and I haven't even touched the big ones like movement speed, jump height/arc, etc.
Additional polish features may be added. Freeze frames came up in a discussion with Matt about 45 seconds ago at the time of writing, and other feel-y feats are sure to come as well.
We're almost there, and I think the game's really coming together!
