PetriPet Watch Game

UX Architect | Game Designer | UI Designer | Graphics Artist | Programmer

Project Overview: I wanted to learn Swift & the WatchKit SDK so I could build something fun for my new Apple Watch.  I brainstormed with my wife and daughter about various games that might play well on a watch’s small screen and limited control options.  My wife had complained that there didn’t seem to be many virtual pet games that ran on the Apple Watch and suggested I consider that kind of title.

The Opportunity: I needed to create a game that would be 100% playable on the Apple Watch.  I only wanted the player to occasionally use their phone for specific things like inventory management or in-app purchasing.  All of the interaction with the pet (feeding, cleaning, praise, etc) needed to happen exclusively on the watch.  The small screen (a maximum 390 x 312 px on the 42mm model) and limited input options (a maximum of 1 long press, 4 swipes and 4 UI buttons) made this a good UX and game design challenge.

Research Findings: Before embarking on the creation of an Apple Watch virtual pet, I did some research in the App Store.  Apple has separate stores for Watch and iPhone/iPad but also cross-lists watch companion apps alongside the full sized versions.  To focus on only apps that were optimized for the watch, I used the Watch App Store.

What I found was that there were only about a dozen ‘virtual pet’ apps for the Apple Watch and many of them hadn’t been updated in over two years.  Due to Apple’s changing WatchKit SDK, many of these apps were now broken when used with the newer versions of watchOS that have been released to date (4, 5).  The featured game in the virtual pet genre was called Egg and upon downloading it to my wife’s Apple Watch we discovered that it didn’t work correctly.  She could only play it on the iPhone. I was also surprised to find that Namco had released an Apple Watch enhancement for their Tamagotchi iPhone game but then subsequently pulled this version after it received low reviews due to bugs that rendered the watch game unplayable.

The most award winning virtual pet game on the Watch App Store is StandLand.  This is a good looking app but it doesn’t feature all of the options for taking care of your pet.  Instead of classic features like feeding and cleaning up after it; the way you interact with your pet is by standing up once per hour for twelve hours per day.  It is more of a fitness tracker with a pet interface than a virtual pet game.

Based on this analysis I decided that it was worth pursuing a virtual pet game optimized for the most recent version of watchOS and feature the classic ‘Tamagotchi’ style gameplay.  I needed a unique twist to make the game stand out so I adopted a ‘mad scientist’ paradigm where the player can experiment with different ‘DNA splices’ to dramatically change the way their pet looks.  This in itself presented a number of UX challenges which I will detail in the next section.

UX Challenges

One of the reasons I chose to develop an Apple Watch game was to experiment with some game design and UI concepts on the tiny screen.  As phones have gotten more powerful and the screen sizes have gotten much larger, I wanted to try taking a technical step backwards and challenge myself with some of the inherent limitations that miniaturized technology creates.

a) Game Design: From a game design perspective, I wanted to create a game that allowed for short bursts of gameplay that would be fun but also nonintrusive to the user.  The challenge with any watchOS based game is that the options are limited.  Apple recommends that interaction be quick (30 seconds or less) and the user interface be ‘glanceable’ as the screen will automatically turn off after a maximum of 70 seconds to conserve battery life (user controlled, default is shorter).  With this in mind, I needed to make sure gameplay activities were quick and specific.

b) Notifications: It was important to me that local notifications alerted the player to important actionable activities but didn’t notify them constantly or interfere with their day-to-day life.  Striking a balance by only notifying the player when the pet was hungry, sleepy, or needed to be cleaned kept notifications to a minimum.  Also as the pet matures, it needs to be fed less often so over time the notifications decrease.

c) Optimization for the Apple Watch: I was very motivated to make an ‘Apple Watch ONLY’ experience as most of the competing games I had seen on the App Store made the watch an optional accessory rather than central to the gameplay.  My game requires the Apple Watch and while that may limit the installed base, I didn’t like how the watch was often treated as an ‘after thought’ by developers on one extreme. The other extreme is that in the interest of capturing a higher amount of marketshare, a developer will shoe-horn a modified version of their Watch App into a full iPhone (or gasp!) iPad experience that just looks like a scaled up watchOS Interface Controller.

d) Flipping the iPhone accessory paradigm: By leveraging the Apple Watch as a requirement, I was able to treat the iPhone as an accessory instead of the other way around.  The core of the gameplay would be happening on the Apple Watch and that allowed only ancillary things to need to occur on the iPhone.  The things that the iPhone really excels at are the things the Apple Watch doesn’t do so well.  For example, I have several inventory items that can be equipped to your pet.  Scrolling through a long UITableView of items on the Apple Watch isn’t very enjoyable but it’s second nature on the iPhone.  So I made sure inventory management was handled on the iPhone and then when a selection was made, it would send a message to the Apple Watch to update the interface and equip that item.  By playing to the individual strengths of each device and having them work together in parallel I created a more natural and enjoyable user experience.

Design Documents

Design Principles Used:

Technologies Used:

• Apple Xcode 10

• Swift 4.2

• Foundation, UIKit, AVFoundation

• WatchKit, ClockKit

• GameKit, StoreKit, HealthKit

• MagicaVoxel, Adobe Photoshop, Adobe Illustrator

• Apple Keynote

Note: I removed this game from the App Store with the release of PetriPet 2 and watchOS 8.

Lessons Learned:

When Contextualization Goes Wrong: In my opinion, Nintendo is the gold standard for gameplay design.  I have always liked the simplicity in their approach to interactive design.  I would rather play Super Mario Odyssey over Red Dead Redemption II any day of the week, even though both are grade AAA titles.  Red Dead just has too many buttons and too much complexity to be easy to pick up and play.  Mario is more accessible but still has depth to the gameplay that isn’t immediately apparent because the complexity is abstracted away with simple controls. Nintendo often implements this simplicity through contextualization.  The same button works to talk with an NPC, throw a fireball, run, or pickup an item; depending on the circumstances and the situation the player is in. 

With that in mind, I wanted to use contextualization whenever possible to limit the number of buttons, swipes, and scrolls necessary to interact with your virtual pet. My initial sketches and wireframes were set to rely on a ‘long press’ gesture to display a contextual menu where the player had the option to feed, clean, give a treat, or put the pet to bed. 

The treat button was set to contextually determine if a pet was sick or not.  If the pet was sick, it would give a medicine pack to heal it — instead of a treat.  During beta testing, I witnessed two things with this approach that caused me to go back to the drawing board and reconsider how this was being done.

• Problem number one: It wasn’t immediately apparent to the player that giving the pet a treat when they are sick would heal them.  To make things worse, the spaghetti code that I had written to enable this capability was error prone and sometimes fed the pet medicine when it wasn’t sick or would claim that there was no medicine available when there was (a big red flag when I’m selling medicine as an in-app purchase).

• Problem number two: When watching players interact with their pet they instinctively wanted to ‘tap’ or ‘double-tap’ on the screen, but never did they instinctively ‘long press’ on the screen.  I would suspect that many new Apple Watch owners have overlooked shortcuts or features because they don’t try to long press the screen very often.  This lead me to re-think about the core gameplay and where to use the double-tap gesture.

I wanted to solve the meds vs treats issue by adding a specific medicine button to the menu.  That way it would be readily apparent to the player that treats are given with this button and medicine was given with that button.  The problem I had was the limitation WatchKit imposes on how many buttons can be in the menu.  I needed five buttons but I could only have four.  

The solution was to move the button to feed your pet to a ‘double-tap’ gesture and free up the feed button for medicine.  This ultimately resulted in a much better experience because it gave some kind of feedback to the player when they tapped or double-tapped on the watch face.  It also cut down on the time needed to feed your pet by several seconds.  Since feeding is the most critical and time sensitive action in the game, upgrading the placement from a menu item to a direct gesture on the main display made a lot more sense.

Auto Layout Hell: It had been a few years since I had used Xcode for anything save for editing a few plist files here and there.  When I had dabbled in Objective C and iOS Development in 2013 and 2014, there was the standard iPhone screen and a brand new 4” iPhone — the iPhone 5!  The nice thing about the iPhone 4s to iPhone 5 migration is the screen just got a little longer.  Auto Layout was brand new and could be optional if you modified your interface slightly to account for both displays.  

Imagine my surprise when I opened my Storyboard editor and found SIX different sizes of iPhone screens (not to mention iPad and Apple Watch) — Sheesh!  That forced me to take a time out from my interface design tasks and take a crash course in Auto Layout.  Ultimately this was a worthwhile endeavor because it forced me to re-think my interface to be more adaptable.  You can see from my initial sketches and refined wireframes that I wanted a very balanced and rigid interface that scaled up to the larger phones.  This worked well for the iPhone SE to Phone 8 to iPhone 8 Plus, but when I got into the iPhone X series the wheels fell right off of this approach. 

If my interface was going to be adaptable I needed to get comfortable with less rigidity and more space between elements on the screen.  Again I took a page from Nintendo and began to look at the iPhone X screen as two separate displays, not unlike the Nintendo DS or 3DS.  There were parts of the interface that were solely for providing information and there were other elements that required interactivity.  I decided to split the view in half horizontally and align the buttons to the lower half to ensure they were reachable by the thumbs of an overage sized hand.  Then I split everything above the buttons off and aligned it to the top of the display.  Thus separating the interactive elements from the informative ones and making sure the buttons were within comfortable reach when holding the phone.