Mobile Game

Bubble Brawl

Date
Dec 2020
Client
Internal Project
Role
Product Design

A game that brings people together, and usually devolves into chaos.

No items found.

A Simple Idea

What if phone games connected people rather than isolating them? By the end of my high school career in 2012, iPhone games were taking off, and I noticed that many of the games required people to sit by themselves. I wanted people to interact more, and wondered if there was a way to do that with an iPhone game.

An idea popped into my head, and I made a simple app design for a 2 player game for one screen, imagining a world where people played together on one phone. I then completely forgot about it.

Eight years later, I decided to learn how to code my own UIs, so I learned basic Flutter. After a few weeks, I realized that I had learned enough to build the game that I thought of years ago. This is the story about how I went about building it and what I learned from the process.

The Concept

It was a simple idea: there would be a red player and a blue player. A single phone screen would be populated with red bubbles and blue bubbles, with both players looking at the same device. Each player would be assigned a color, and the first person to pop all the bubbles of their color would win the round.

I liked that it was easy to understand, and not restricted to any age group.

Philosophy

While I’m not a mobile game enthusiast, I wanted to make the experience as clean as possible for the players, and I would have to take my lack of experience into account.

A game is different from an app with a specific purpose. Whereas most apps are a means to an end, and you can measure the success of the app by how well the end is reached, a mobile game is an end in itself. Its purpose is simply to entertain the users.

This meant that it could be tested anywhere, with any people, so I could walk up to any group of people on the street and get feedback on the game without much delay.

Talking to a Game Developer

I luckily had a friend that successfully brought a game to become #12 in the app store. Interestingly, this success came from copying a different game, and improving on some simple gameplay tactics. He said that people get way too obsessed with the aesthetics of a game, but the gameplay and rewards are what really hook people.

He iterated on 28 different concepts before one game took off.

The lesson: try new things quickly, and focus on small tactical changes to the experience, and see how people react.

Factors

These were the following variables I decided were important to the game.

  • Visible delight in the gameplay itself
  • How long people wanted to play the game for a particular session
  • How often people showed the game to others in the group after a session.

Iteration Process

Step 1: Testing the Concept

For the very first run, I placed bubbles randomly on the screen, and just tried it out with a few friends. The random bubbles would overlap, and were generally unacceptable for a production app. But, to my delight, people got really sucked into the game. The concept was validated!

Step 2: Making It Nice

I made the bubble arrangements account for collisions, and I took a second to make the whole design a little nicer. I went with a laser tag look, as it was one of my favorite childhood games.

One of the early issues with the prototype was that users received little feedback when a bubble was popped, and would get annoyed tapping a bubble multiple times. So:

  • I made the hitbox of each bubble larger than the visual
  • I added collision detection in the generation function
  • I created a pop animation that extended past the finger, so users could easily see when their pop was successful.

Step 3: Keeping Score

After I created the bubbles looked nice, I figured people would want to track their progress, so I added a scorebar to the bottom of the screen. Inspired by other game mechanics, I added a streak.

Step 5: Creating a Way to Save Games

To encourage repeated play, I thought I would create a system where different players could save their scores. Users would enter their names before the match, and the games won by each player would be saved to the device.

I was inspired by the few games I had played, and thought saving progress would be important, but I didn’t consider the context. Call of Duty or The Sims are complex games that take significant mental effort to progress in, whereas this game was significantly more casual. The act of popping the bubbles with another player was significantly more rewarding than making any progress in the game. Ultimately, I ended up removing this system.

Step 6: Adding a Tutorial Screen

On a cold October evening, I was sitting in an NYC deli, and walked up to two really cute girls. Instead of hitting on them, I asked them to test out my game. I told them I wasn’t going to tell them what the concept was because I needed to see what was the natural reaction to the design.

My friends who knew about the concept, started popping the bubbles, but these girls tried dragging them, and running their fingers into them. It was clear that the look of the bubbles wasn’t clear enough that the user immediately knew to pop them.

People learn best through experience, so I added a tutorial screen, that interactively showed people how to play the game.

With this screen in place, people would know how to play the game without any additional instruction.

Step 7: Removing the Score Bar

Originally, the game had a scorebar that tracked total wins, and the streak of each player at the top and bottom of the screen.

I noticed that when a round was taking place, and fingers were smashing against the screen, no one bothered to look at the score. I ended up removing this from the game screen to make extra space for the bubbles, and only put the score system on the win screens. I added a cool gradient to denote colors, but people began forgetting what color they were as they were popping bubbles. We added a simple message on each side, so that people got used to their color.

Step 8: Experimenting with Match Mechanics

To make the game more engaging long term, I thought I would create a “tennis match” system for the game. Each session would have a “total matches” variable, that specified the total number of games that would be needed to win.

At first I tried listing out these numbers on the screen, with the total number of matches each person won, and the progress of the rounds in each game.

It turned out to be a little confusing. Basically no one understood how the match system worked, and they just pressed ready ignoring the match system.

Step 9: Removing Numbers Altogether

I figured that even keeping track of score was too intense for this game. Let’s throw away the numbers altogether, and just use graphics to communicate the progress within the match.

The screen became much more clean as a result. People also got intuitively got that the first person to fill out all the bubbles won. Success!

Step 10: Toning Down Match Length

When I first made the game, people would get super sucked into the gameplay, and play for 12-25 rounds without realizing what they were doing. Ironically, once we got the match system in place, people started to get discouraged to play for more. “Agh, I don’t know if I can do all 15 rounds”, was a common sentiment. I decided to change match mechanics to 3 per match to see if the number was the problem.

Step 11: Abstracting Progress

Our next experiment involved making progress easier to qualify. We added progress to the match system in the form of different ranks completed when users played multiple matches in a row. This hasn't been tested in the field yet.

Next Up: Spicing Up the Gameplay

This is the game version we are building now. We take the game to a new interesting place by adding a bubble where people. The idea is that in rather than focusing too much on "Loyalty Programs" we now actually make the product more engaging. I am excited to see how people react to this version, as popping a bubble could either be your bubble or your opponents, which will add some interesting dynamics to the game.

Lessons Learned

Add a Clear Focus for Each Screen

When you are designing a house, you are making a static object, so there is only spacial design, but when you make an app, you are designing a dynamic object that changes as the user’s state of mind does too.

It made no sense to show the score while users were playing. Rather than having a persistent score bar on every state of the game, it made more sense to utilize the real estate of non-play states to convey the information users needed. It's important to consider the purpose of each screen, and make sure each element on the screen lines up with that purpose.

In the first iterations, we persisted the scores and color indicators through every stage of gameplay. By removing them from states where they were unnecessary, the game became much more clear.

Make Small Steps & Test

A large theme in my early software and entrepreneurial career was a habit of thinking of huge goals, coming up with a “rocket ship” solution to the problem, then getting overwhelmed.

While iterating on the match system, and the match system and saving system, I also designed a social sharing system for scores, and then scrapped it. If the game was too casual for saving scores, it wouldn’t be interesting enough to share. 

I now want to focus on improving the gameplay, but I have no idea which improvements will actually make the game more fun. So, I want to focus on making tiny updates, and very simple power ups. In this way I can quickly tell whether or not the improvements help people engage.

Respect the Nature of the Game

This is a hyper casual game, and I tried too hard to add elements to the game that would only work in more devoted environments. In the future, I would evaluate ideas comparing the nature of their origin, and the environment I plan on applying them in.

Symbols Often Are Better Than Text

Once I deleted the number system for keeping score and replaced them with dots, people understood the match system much more intuitively. This reminds me of Don Norman’s point, where people try too hard to “explain” how their design works, rather than making the design more understandable for humans.

The dots system for scoring was an example of that type of improvement. People understood filled and empty circles more naturally than numbers. It was a simple change with significant impact.

Progress Can Distract From Play

One of the interesting things I noticed when people were using the match system, is that the winner typically wanted to continue playing, but the loser started hating the game. The winner would have to find another person to play with him, and in that process, they typically got discouraged too.

This is a phenomenon that also happens in tennis; people get obsessed with score, and start playing poorly.

Even when the match system was made simple enough to the point where people could understand it, people played for shorter periods of time. It was a chore to get to the end of the round. Without the match system, people would play on average 20 rounds together, and not think twice about it. Comparing progress actually made the game less fun.

Reward Play Collaboratively

One of the constraints of a 2 player game on one phone, is you need to hold the attention of 2 people to keep it going. The winner typically wanted to continue playing, but the loser started hating the game. The winner would have to find another person to play with him, and in that process, they typically got discouraged too.

For play to keep going, both players have to be excited about the game, even if one is losing. Perhaps I could create a goal that both players reach, just for playing together.

Another One...

See Other

Projects