Blog #5: How playtesting shaped one of our core mechanics
|
Hello and welcome again to my blog! I am Léo and Scrum Master of Team Wendigo. Today, I will talk about playtesting and how it has affected the development of our game, “Umibōzu”. Playtesting is a crucial part of game development. Whether a mechanic is “fun” in a game is often discovered through the iterative and incremental nature provided by the Scrum framework (check out my blog post on Scrum). The Empiricism principle (“inspect and adapt”) as well as the Emergence principle (as we develop we learn about the game) are what enable us to explore what is “fun” in a game. A game can have the cleanest, most spectacular code and most beautiful, breathtaking art but not be fun. This can often be attributed to the team not testing the game continuously and appropriately throughout development. In Fundamentals of Game Design: 2nd Edition, Adams (2010) states that “everything you design must be built, tested, and refined as you go” (p. 51). Therefore, we need to test games as early as possible starting with paper prototypes and continuing on with controlled playtests throughout all stages of development. Only then are we truly able to refine mechanics, game feel, narrative etc. to be captivating and immersive. In “Umibōzu”, the player sets out on a journey in search of the legendary mythical entity Umibōzu. The player controls an old Japanese fishing boat navigating through a thick fog that hides the true nature of objects and beings. In order to survive the journey, the player must resourcefully use their spotlight to avoid enemies and obstacle while collecting power ups. The core mechanics of “Umibōzu” are shooting the harpoon, using the spotlight, and moving the boat. Core mechanics “determine how the game actually operates: what its rules are and how the player interacts with them” (Adams 2010, p. 286). In this post, I will focus on how we refined the shooting of the harpoon mechanic through iteration and playtesting. At the very early stages of production, the harpoon was a small brown rectangle on a larger white square rectangle (the fishing boat).  Before any art assets were implemented, we had a sound for the shooting of the harpoon. The sound was a free sound I found of a catapult launching a projectile. I added some effects such as reverb and changed the pitch to better suit the harpoon in our game (first iteration of the sound effect). The sound of the catapult consists of a short initial sound before the actual launching of the projectile, followed by a heavy release sound. After implementing the sound into the game, we tested it and noticed that the shooting of the projectile in game had to be slightly delayed in order to synchronize with the sound. Having our mechanic function like this was not intentional at all and was solely discovered due to the testing of the implemented sound. Despite it not being an initial design decision, we liked the way it worked. It felt a bit clunky to click and then have to wait briefly for the projectile to actually shoot but once you got used to it and made the connection with the sound, it made total sense and became intuitive. A couple of weeks later we had our first playtest right before the Alpha presentation. We had students play our game and then interviewed them using our phones as tape-recorders. A questionnaire with 8 questions was provided and respondents were given freedom to answer them as them as they wished. In total, we collected 24 recordings with an average length of 4 minutes. The recordings were transcribed and compiled into a document. I will only focus on one of the question: What are your thoughts on the harpoon shooting mechanic and the harpoon projectile? Here are some of the responses of playtesters:
Based on the feedback, it was clear that the mechanic was received overwhelming positively. Nevertheless, there was still a lot of work to be done for the delay to be communicated more clearly to the player. We held a design meeting a week after the playtest and thoroughly discussed how we could improve this crucial part of our game. We figured that instead of only a single click, the player would need to click and hold the mouse button down to give a sense of charging up the shot. Once the projectile was fully charged, the player could release the button at their desire and fire the projectile (here is the revamped sound). We also wanted to provide some visual indicator to further communicate this component to the player. Unfortunately, we were not able to implement the visual aid in time for our second playtest. We conducted the second playtest differently this time. We set up four computers, two with the game and two with a Google survey. This proved to be an effective method to collect many responses.  Again, we asked players the same question: What are your thoughts on the harpoon shooting mechanic and the harpoon projectile? Here are a few responses:
Awesome! People really liked the new addition but still, the visual indicator was missing. Based on the feedback, we further improved the mechanic to also have a visual indicator for the harpoon charge up. Now, there is a yellow spear shaped indicator which turns red when the harpoon is ready to be fired. All in all, I have learned a great deal about iterative development and playtesting. I think it is really cool how we “found” this mechanic unintentionally. Due to early testing in development and constructive player feedback, we were able to discover value in our core mechanic and refine appropriately. Thank you for reading and see you next week! Cheers, ∼ thedudeleo  |