Month: April 2020

Final Blog Post – Gold Sprints! Playtesting & Postmortem

Final Blog Post – Gold Sprints! Playtesting & Postmortem

As of today, Project Blue, titled Io, has gone gold! It’s been a wild ride, but the game feels great to play. These last two weeks, surprisingly, slowed down a fair bit. My work consisted primarily of playtesting and tuning for values and controls, with some bugfixes thrown in, and I’ll do a small postmortem as well.

Playtesting & Tuning, Round 1

There isn’t really anything for me to show off here, but I will share findings and thoughts about how I playtested and how I could improve in the future.

After the changes I discussed in my last post, I needed to playtest to ensure that the values were good enough. I only grabbed a couple of people for this playtest, just for a preliminary test, and sent them a custom build. In a discord call, I had them screenshare the game with me while they played. I gave them a list of changes, which they could look at if they wanted to or could ignore, and had them play the game and free-associate about what they were experiencing. One of the testers did read the changelist, and one didn’t. I got valuable feedback from both of them – most of the changes looked and felt great to them, though there were some important changes that could be made. The sword throw momentum and wall slide speed both could be increased, and attack range was better but not quite there yet. Other changes were small, but noticeable, but nobody noticed at all that Io was smaller.

However, I think the way I did this playtest introduced a fair number of problems:

  • I only got two testers, so results were hard to totally trust on account of a small sample size. Both testers were also very familiar with the game, so they had habits and ideas about how things should work already.
  • Reading the changelist in advance biased the player who had read it in a noticeable way. He found himself constantly aiming high with his sword throw because he feared that the momentum would screw him up, so I had to ask him to pretend he didn’t know it was there and replay the section.
  • One of the testers had some wacky habits with how he played the game that made it so that he didn’t notice the wall slide changes, as he would constantly be interrupting his slide.
  • I didn’t record any video, so all I can refer to is my notes about the playtest.

I took their thoughts into account and made some changes: Sword throw momentum was slightly increased, and Wall Slide speed is increased as well. The attack range was increased, though the change didn’t get merged into the main branch for a while for some reason.

Playtesting Windmill Controls, Round A

After that, I was asked to work on the control scheme for grabbing windmills with keyboard and mouse. This wound up taking a fair amount of effort, as this mechanic requires a lot of testing still anyway, and with a keyboard is extremely awkward. Initially, this was bound to middle mouse click, but we could not rely on players having a middle mouse button, so we needed it to be a key.

There were two rounds of playtesting for this, as well. The first round, I also only got a couple of testers and had them play a build where grab was bound to ‘Q’ and a build where grab was bound to ‘Space.’ Going into this round of playtesting, I had expected ‘Space’ to be the clear favorite, as I found that holding the key until you release from the windmill felt good.

This test pretty immediately showed me the problem with such a small sample size: both testers gave me conflicting feedback. One strongly preferred ‘Q,’ as the muscle memory needed to use ‘Space’ (which was already bound to jump) was giving him trouble, and he felt that releasing space to get launched was counter intuitive when, for the rest of the game, you needed to press space to jump. The other tester hated ‘Q’ because it was impossible to move left while pressing ‘Q.’ However, they did not like ‘Space’ either, for similar reasons as the other tester, but found it to be more tolerable.

This had a few problems – again, small sample size was an issue. Neither tester had played the Windmill Fort before, either, so they had to spend a lot of time learning how to use the Windmills, which did not function properly at that time. Once they had adjusted with one button, they presumably had to spend less time adjusting with the other, which may have affected their preferences: they might have grown accustomed to the first one they did and disliked the change, or they might have hated the first one and thought the change was clearer. Additionally, due to scheduling I was unable to watch, so I only had what they could tell me after the fact.

So not only was I totally wrong about the preference for ‘Space,’ but the feedback I got left me in the same place as before. Ultimately, as the game mostly involves moving to the right, I settled on ‘Q’ as a temporary measure due to a lack of time before the Pre-Gold build.

Observation Testing and More Windmill Controls, Round 2 & B

In the pre-gold studio meeting, very few people made it to Windmill Fort, so we got little Windmill feedback there, but people were generally pleased with the way the game felt. In my own playtest, I noticed that, due to a change in how throwing the sword worked, if you threw the sword and immediately teleported, you might get teleported backwards, so I fixed that. For many people, this would have no effect, but the way I play the game involves a lot of small micro-throws that only cover a small distance.

After that, I decided I needed more playtesting. All of the feedback on general player feel in that meeting was positive, but there was little specificity – many testers just said “it’s good,” so I figured I should get more feedback. Additionally, I was highly dissatisfied with ‘Q’ for Windmills, so I wanted to test that, too. I created a basic Crystal Caves build where I wanted to watch people play. I also sent out several additional builds of Windmill Fort – one where jump was bound to ‘Space’ and one where jump was bound to several keys: Q, W, S, V, and Alt. This time, I also selected several more testers, which made me a bit more confident in the results, and I watched each one.

First, I watched each player play through the Crystal Caves without any input of my own (besides hints if they got hard-stuck at an obstacle). I asked them to tell me any thoughts they had, which had its pros and cons. Then, after they finished, I asked a few questions about specific parts of the game. After that, I had them play through Windmill Fort on a keyboard and I watched them play. Windmills were still wonky, and many of the testers had never used them before, which had some pros and cons.

Watching players play through the Crystal Caves took a while, and pretty much all of the responses I got back were “this feels good,” though there were occasionally some important details here and there. I wasn’t left with a lot to change. As for the Windmill Fort, players universally found W or S to be substantially better than anything else, and the difference between the two seemed to come down to whether or not the player’s finger naturally rested on W or S. All of them thought these were weird at first, as W and S are traditionally used to move up and down/forward and backwards. We settled on W, as all players liked both, but more preferred W.

Some problems with this playtest:

  • I didn’t ask many questions while they played, so they might not have paid attention to anything I was looking for. I wasn’t looking for much in particular and just wanted to see if I could facilitate the way they played, so maybe the playtest was barking up the wrong tree from the beginning
  • The lack of specificity meant I received a lot of feedback on topics that were mostly irrelevant to the player. While pointing out things like background parallax issues is useful, I couldn’t do anything but mark it down, which might make me miss other feedback. Other testers gave a slew of negative feedback, which made it hard for me to decide what to do next.
  • I had to send one build with multiple buttons bound to Windmill grabbing. Several testers found they instinctively held down W or S when they jumped or fell, so there might have been some strange interactions between jump buttons.

Throughout all my playtesting, I also noticed that nobody played the game like I do, which involves a lot of small micro-teleports and fast movement – I wonder if this comes from my own testing of these mechanics?


Ultimately, I’m very happy with how this project went. I think early on, the team was struggling to get started, and didn’t know what to do with many members – my first weeks, I had very little work, and I wasn’t alone in that. As time went on, we adjusted, and that seemed to be mostly corrected as time went on. I felt that communication about decisions made by leadership could have been documented a bit better, but generally I think it was pretty good. Once the Covid outbreak started, all bets seemed off, but I think we adjusted quickly. Since most of our work happened remotely anyway before the outbreak, I think people did a great job adjusting, though online meetings were difficult. It was disappointing that we had to cut so much, but totally understandable. Ultimately, I think Io came out to be a pretty good game, all things considered.

As for me, I think I did pretty well. Early on, I struggled to get things done, but once I started to do work outside of enemies I think I started to do best. I wanted to work in the enemies pod because I thought I would do a good job coming up with ideas that are good foils to the player. I think my initial design concepts would have worked well in this regard, but they were pretty ambitious and turned out to be out-of-scope for the team. I was pretty disappointed to see how much they were trimmed down at first, but it was definitely necessary.

When I was asked to work on other pods, I was pretty nervous. It felt like enemy designers were mostly done with their work, so we needed something to do, but level design isn’t my forte. I accepted the task anyway, as I felt this would be a great time to grow. When I was soon afterwards asked to move to the player pod, I felt it was a blessing and a curse – I am pretty good at polishing things, and I’d had a lot of small thoughts about how the player could be improved, but I did lose out on the opportunity to hone my level design skills and had to toss the level ideas I’d already come up with. I’ve received a lot of good feedback about the changes I made to the game towards the end of the cycle, and I do think these changes were absolutely vital to making the game fun to play. I don’t think I had to be the one to do them, but I’m glad I got the chance, because this feels immensely gratifying.

However, I don’t feel quite like I’m done: I have more ideas on how to improve the player. Acceleration changes, animation curves for jump arc, etc. I also still want to implement a few more enemies, and I want to make that level I had been working on a reality. Hopefully I get the opportunity to work on these over the summer, because I think there’s a lot left that I could do.

As it is, though, I’m very happy with my contributions to the project. I think I’ve gained a lot of meaningful experience with team communication, testing, and programming in a team environment. I’ve gotten a lot better with Git, and I feel more confident in my Unity skills. I’m excited to see where I take this knowledge next, because I think it’s going to help me a lot in the long run.

Fifth Post – Beta Work – Level Design, Controls Updates, Player Feel

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 will 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!

Theme: Overlay by Kaira
Ann Arbor, MI