Donut Drop
Project Overview
Outline
Behind The Project
For one month, I developed, tested, and iterated on Donut Drop, a browser-based puzzle game inspired by the popular “suika” (watermelon game) genre. The core goal was not just to build a game, but to rigorously experience and pass a professional platform’s quality assurance pipeline. I submitted Donut Drop to Poki Games and went through their formal QA process to understand what makes a game engaging for a casual audience.
Research
Poki Games provided plenty of guides so developers know what kind of games they should aim to make for their platform. One of the main guides I used was their Poki Player Device Report which is constantly getting updated each month. It shows the statistics of what type of devices players use (phones, tablets, PCs, etc.), what kind of browsers players often use, and even what operating systems players typically have.
The process for my game idea began by analyzing successful suika-style games already on Poki and similar platforms. I focused on:
- Core Gameplay Loop: What made the mechanic of combining objects satisfying?
- UX Clarity: How were rules communicated? How was feedback (like combos) delivered?
- Session Length: How did these games encourage players to play again?
- Visual Hierarchy: How did they ensure the player’s focus was on the critical gameplay elements?
The other suika-style games on Poki had the main core gameplay being very similar, but what made it unique was the visual themes outside of fruits. The original suika game had fruit as a core visual theme, and some of the ones on Poki also had this. But I wanted to make a theme that was unique but had similar circular object shapes. I eventually went with a donut theme since it would be easy to create different variations with a similar shape.
This research solidified my vision, which is making a minimal, satisfying game where players combine dropping donuts to create bigger donuts.
QA Testing and Iterations
This phase was the core of my learning, where I applied a formal QA pipeline to iterate on Donut Drop. Using the developer tools provided by Poki, I was able to go from assumption-based design to data-driven refinement.
Leveraging Poki’s QA Tools
To ensure my game met platform standards, I utilized several key tools provided by Poki:
The Poki Inspector
This was my primary QA environment. It provides a detailed, automated checklist to verify technical and design standards—from performance to ad integration. Features like Poki’s SDK for ads would auto-validate if the feature was working correctly, streamlining the QA process. This tool was critical for identifying and squashing bugs before any user ever saw the game.
Here is what the preview of the QA checklist from Poki looks like up close in the inspector:
Structured Player Testing:
Poki facilitates a formal Player Fit Test, where a test game is exposed to 500 players over a minimum of 3-hour session. Passing this test is a key indicator of a game’s potential for high engagement on the platform, and is a requirement set by Poki to pass so the game can be moved along to the next stages. I used the version notes feature meticulously to track which build was being tested and to document my hypotheses.
Playtest Recordings & Analytics:
The most valuable tool was the playtest recording feature. A small group (~10 players) would have their sessions recorded, with data on device, region, playtime, and even console logs for crashes. Watching these videos was like a live usability study, as it showed me exactly where players hesitated, got confused, or became engaged in the gameplay.
Here is a screenshot of a list of every single player from playtesting. Developers can request up to 10 player screen recordings at a time.
Here is another screenshot of what the recording looks like for a player. The keyboard below shows which buttons the user was pressing if the game involved using the keyboard. This also shows the console log that was running while the player was using the game.
Integrating Ads
Ads are a vital part of the Poki’s platform. Because of this, I treated ad placement as a core UX constraint from the start so it does not. Poki’s inspector provides ad integration testing, so I used the Poki Inspector to rigorously test this feature and make sure it was working properly.
I designed ad placements to be visible but non-intrusive, opting for optional interstitials that players could choose to engage with. Playtest recordings confirmed this approach worked, as ads did not disrupt the gameplay flow or cause early drop-offs.
Changing Container Size
One of my most significant findings ending up being counterintuitive in the game UX design. I believed a smaller play area would create tension and encourage replay, but the data told a different story. What I initially thought was a smaller container that holds all of the donuts leads to more frequent “game over” states, which in return could encourage replaying the game.
But after running through several playtest sessions, a larger container resulted in higher engagement. The smaller container made the game feel punishing and less accessible, often giving players a sense of conclusion that resulted in them leaving. The larger space made the game feel more forgiving and enjoyable, keeping players in a flow state for a longer period of time.
Here’s a comparison of the container sizes for visual reference.
Here’s a chart provided from Poki’s QA tools that showed how much engagement was between these versions.
The Failed Tutorial
Influenced by other games on the Poki platform, I added an introductory tutorial so players would have an easier time with onboarding. However, the playtest analytics revealed it was a point of friction rather than helping the player.
- The Problem: The tutorial delayed the core gameplay loop. Players wanted to jump in and learn by doing. I also discovered a critical alignment issue on desktop that made the tutorial screen look unpolished thanks to Poki’s inspector.
- The Solution: I removed the mandatory tutorial entirely. Playtests showed new players could intuitively grasp the simple merge mechanic within seconds, making the tutorial an unnecessary barrier.
Refining the First Version
After several iterations, the data consistently showed that added features like higher difficulty and unneeded tutorials reduced player engagement. This was a great lesson in preventing feature creep and only refining what was necessary.
I pivoted back to my original Version 1.0 concept and focused purely on refinement with these features:
- Maximized the container size for difficulty accessibility
- Polished visual feedback for donut merges
- Streamlined the UI to absolute essentials
- Ensured ad integrations were seamless
Reflection
While Donut Drop was not ultimately published on Poki, the experience was invaluable for understanding the importance of UX and QA roles, and how the process of iteration design would work.
What I learned:
- The Importance of Data in QA: Some of my assumptions about “better” features were directly contradicted by player interaction data. This cemented the importance of letting analytics guide design decisions, not just intuition.
- Simplicity Over Complexity: A minimal, highly polished user experience often outperforms a complicated one. Removing friction is key to engagement.
- The Critical Importance of Documentation: A significant reason the project didn’t proceed was my initial failure to fully comprehend all of Poki’s technical and content requirements before diving into development. This taught me a crucial professional lesson, which is to always completely understand the specifications, constraints, and success metrics before committing significant resources. It’s a lesson in thoroughness I will carry into every future project.
This hands-on experience honed my core skills around UX design, design iteration, and QA testing, which is a foundation I’m ready to apply to professional product development.