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.