top of page
Treasure Party Banner 3.png

Treasure Party is a match-3 mobile game where you use matches to clear obstacles and progress through a board game style treasure adventure. I worked on it during my time at PlayQ. I designed levels, playtested new features, and documented bugs.

Designing the Levels

My process for design levels usually started with a novel concept. Something that differentiated the level from others, whether that's giving a particular challenge, using an interesting combination of mechanics, or some unique visual theme. Then, I would adjust the level to fit in with my 3 design principles:

  1. The player should never have to make a useless move.

  2. The player shouldn't have to make the same move twice.

  3. There should be as little variance between the most and least amount of moves to win as possible.

Finally, I would balance the level to make sure it fit with team standards. Below is a video that explains the design principles further in depth and shows how this process is used to create a finished level.

Video in progress

Biggest Success: Trusting My Instincts

I decided on my design principles very early on at PlayQ and my time there only confirmed that they were good ones. As we collected more data, a consistent pattern formed that the more a level adhered to those principles, the better they performed in engagement, retention rates, etc. What especially gave me a lot of confidence was that I don't play casual match-3 games. I tried out Candy Crush when it was just getting popular and that was about it. So the fact that I was able to intuit what match-3 audiences wanted, despite very little experience with the genre myself made me feel like I have a good understanding of different types of gamers and how to design levels to match those tastes.

Biggest Failure: Getting Too Comfortable

This was my first time working on a game for longer than a few months, so I got to experience how communication styles can change on a project over long periods of time. Initially, I was very cautious, always checking in, always making sure that I was on the same page with everybody else. And I think to an extant, it's normal for that to go away after a while. Not needing to communicate so much can be a sign that you know your team well enough to trust what they're going to do and vice versa. So it makes sense to avoid being redundant, it's efficient. But I also think something can get lost along the way. You lose opportunities to build rapport and to share findings and tips that might not be urgent, but are helpful in the long run. I can't help but look back and wish I had gotten to work closer with my teammates.

Biggest Lesson: Adjusting Workflow

This was my first time working on a live service game, so there were stricter quotas than I previously worked with. In order to make sure I hit those quotas every day, it was important to maintain a more rigid workflow. However, as new data and tools are introduced, they often caused changes to those workflows. Initially, I really struggled with this and my productivity would drop for a week or 2 while I adjusted. The reason for this was that I would attempt to maintain my old workflow and only make changes when it became clear it was absolutely necessary. Over time, I got better at analyzing the changes and adjusting ahead of time, rather than trying to figure it out through trial by fire.

bottom of page