Hook and Throw is a two player coop game where you play as the viking inventor Tyra and her masterpiece invention, the robot Thrym, in a bid to free the north from roman occupation. In this alternate history, the romans have adapted steampower much earlier than in our world, and used that technology to fuel an army of robots that conquered Europe. Now play as the viking heroes, using your unique skills and teamwork to battle the romans and free the north!
This game was made in a team of about 9 people during the span of 7 weeks using the Unity engine. During this project I was responsible for the level design and the gameplay testing, spending a large amount of time testing the game not only internally, but also with external testers.
The main mechanic of Hook and Throw are, as the name implies, Tyra’s hook and Thrym’s throw. One player plays a small inventor that can pull objects towards her with a hookshot, and the other player plays a large hulking robot that can pick up and throw objects. This dynamic allows the duo to cooperate to solve puzzles and defeat enemies to make their way through three handcrafted levels.
We spent a lot of time trying to differentiate the two players, making them both individually fun to play, but also not too omnipotent to make your friend irrelevant. This was a difficult balance to find and I spent lots of time testing and tweaking levels to make sure both players had their time to shine and to sometimes enforce teamwork.
Most of my testing was done solo, only occasionally bringing in a friend to test with. This may seem odd, given that we were designing a two-player game. However, as the primary concern with the game and level design was to ensure that both players felt satisfying individually, and that they had to cooperate, I used my solo play to alternate between the two players, measuring how often I needed the second “ghost” player to progress. This also allowed me to focus test one players mechanic in relation to the puzzles. How difficult was this door to open for player A, how dfficult was it for player B?
Levels were designed with an intended solution in mind. Then, I tested to see whether it was possible to do so. Then, it was all about breaking it. How many ways could I get through the level that wasn’t the intended way? Sometimes, it just so happened that I could solve the levels without ever touching the second controller. Then I knew there was a problem and something had to change.
Every now and then, I also brought in people from outside our group, or let people inside the group who weren’t as experienced play through a level, watching how they approached the puzzles. In certain cases, it became very obvious that the players focused on the wrong thing, or that their first solution was completely different from mine. Sometimes, I changed things to encourage players to stop attempting their faulty solution, sometimes I changed the puzzle so that solution instead was correct.
In the tutorial level for example, there’s a segment where one player has to stand on a button to open a door. The second player then walks through the door and fetches a box, going back to put it on the button so that both players can get through. What most players did here however, was to have the player with hookshot walk through the door and attempt to hook their friend through the door before it closed. The intention of this puzzle was for the players to realize that sometimes one player has to be a “key” so the other player can progress elsewhere. Thus, the button was moved away from the door so this solution no longer became as obvious, and more importantly, if the players tried it, it obviously failed, instead of being “just barely close enough”.
However, I also noted what types of solutions players attempted and tried to implement those elsewhere. Level two for example has a puzzle segment where you are intended to pull each other through the doors. Level three is then built in a split arena. Learning from the issues in the first level, I designed this level so that the players were forced to split before it became an issue. The players cannot enter the arena through the same door, to avoid the issue apparent in the tutorial.
Overall, much effort was put into making sure players could do the things they wanted to do, that they could solve puzzles in a way that made sense when they figured it out. Sometimes the puzzles were about proper execution, sometimes they were just about figuring it out. Sometimes, the first thing players thought of was the correct solution, sometimes, the puzzles intentionally prevented the first obvious solution. Finding the correct mix of these took some effort, but I believe we succeeded.
Most importantly, we succeeded in making sure both the players had fun playing their character. Nobody felt like a liability, both players had their niche and felt cool. I believe we could not have achieved this without the rigorous testing we had. In the end, we delivered a satisfying coop experience, and I’m very happy with the result.
This project is very important to me as it’s perhaps the first project where I’ve had the time and resources to actually get into proper QA. It was very fun to work on this project and I felt I had a large impact on the final product, even if most of the game was made by other people in the group. I felt like I had a hand in all aspects of the game and I really enjoyed being in the middle of it all.
Oscar Wirz 