With a new year comes new projects, and so I retired one of my very first portfolio case studies, a side-scrolling mobile game app called Hootie Puff. I decided to recap some of the learnings in this post.
Challenge: My partner and I were tasked with creating a mobile game in a tight deadline. The game had to be designed, developed, and accepted onto the iOS and Android app stores within 12 weeks.
Solution: We created a mobile side-scrolling game called Hootie Puff. The game featured set goals and levels to appeal to the casual gamer. With each level advance, we hoped players would feel satisfied and accomplished, yet challenged enough to continue playing.
Role: I led the UX and motion design efforts, and my partner Grace Tooher created the music and sounds. We both owned the visual design, animation, and development of the game. We took on this project as part of our Creative Digital Media master’s degree at the Dublin Institute of Technology.
Producing a game is an interesting challenge in narrative and design. The market is already saturated with casual games—more than 260,000 existed on the iOS app store alone at the time of our project. We set out to create a game that was a cut above the rest. Specifically, we focused on crafting a compelling narrative, producing great visuals, refining the interactions, and delivering a sound user experience. We aimed to not only design an enjoyable game that we would like to play, but one that truly resonated with users.
After completing our user and domain research, we solidified our initial concept of Hootie Puff. Here’s how it works: Users must maneuver Hootie the pufferfish along the ocean floor and dodge perils like sharks, squids, and underwater volcanoes by floating above or under them. If Hootie collides with adversaries, he blows up in shock.
We modeled the user flow and wireframed key screens in the games. Because we were responsible for development, actually making a version of Hootie Puff in GameSalad was the easiest way to prototype it. Once the game was in code, we could better tailor our visual assets. For instance, we gave users an incentive to keep Hootie small by adjusting the platform levels in a way that gives preference to Hootie at his smallest size, which we could only do with the true pixel count.
Some of the most significant takeaways that informed our game design are recapped below:
Winning Strategies. When we directed users in our testing sessions to “win the game,” they behaved differently. At the two extremes were, what I called, the “shrimp-gatherers” and the “finish-liners.” The shrimp-gatherers focused on earning points by collecting shrimp and felt that they won the game by beating the high score. In contrast, the finish-liners sped to the end, and felt a sense of accomplishment when they beat a level. Most users employed a combination of both strategies.
This prompted us to make sure the shrimp-gatherers were duly recognized for their efforts. We added a line at the start of each level displaying the number of points earned thus far and a high score section.
Controls. Our game supports three actions: go left, go right, and float up. Early testing revealed issues with the placement of our controls. Initially, we planned to put the right arrow on the right side, and left and float arrows on the left side, in order to leave the right-hand side of the screen as visible as possible. We quickly realized, though, that this control design was unwieldy for users, who found it difficult to quickly press vertically stacked buttons.
Our testing showed that controls placed on the actual game scene, which engage both of the users’ hands, are the most effective. We also learned that separating the left and right arrows from the float arrow worked best (modeled after the game Spout).
To make sure the right side of the screen is visible, we moved the float arrow some distance from the screen edge, and lowered the opacity of all controls by 50%.
The Instructions Screen. In our first few iterations, we included an instructions screen, but only one in five users in testing bothered to view it. Most launched straight into gameplay.
About halfway through the project, we decided to omit the instructions screen. Instead, we created an animated sequence on the landing screen that illustrates the main game mechanics—Hootie gliding over a shark, colliding with a shark and blowing up, collecting a shell and returning to a normal size, getting a shrimp point, swimming atop a platform, and swimming into the light that triggers a level change—all in seven seconds.
We received very positive feedback about the animated sequence, and users did not seem to miss the presence of an instructions screen.
Feedback. In Hootie Puff, visual feedback had to be sufficient in case users had their sound turned off. In cases where the interaction was uncommon during gameplay, we used animation (e.g. collisions with squids and volcanoes, and Hootie’s death scene). But in cases where the interactions were near constant (e.g. Hootie colliding with sharks, shells, or shrimp), we decided to go with sound and a Boolean state change only. For instance, sharks are visible until they collide with Hootie, after which they immediately disappear without an animation or transition sequence. In all interactions, there are audio cues as well.
We successfully submitted Hootie Puff to Google Play and the iTunes App Store within the 12-week deadline. Our feedback from users has been great (best review so far: “Pufftastic! Loads of underwater fun!”)
Feel free to download Hootie Puff for free on your phone, or play on the web here.