Inspiration
The goal with Scoop Days! was to create instant fun, something players could understand almost immediately, while providing visual feedback, progression, challenge & ton of replay-ability.
I took inspiration from games like Overcooked and PlateUp!, where a small set of actions can create pressure and meaningful decisions. I liked how a simple room layout could lead to different strategies depending on where things were placed, what the player had unlocked, and what decisions were made. Scoop Days! explores that idea as a compact mobile management game built around an Ice Cream Parlor.
What it does
Scoop Days! is a single player ice cream parlor management game where you begin as a trainee learning how to take orders, prepare ice cream, serve customers, collect payment, and keep tables ready before customers lose patience. The first time a customer looses patience and leaves the day is failed. If you serve all customers for the day you advance to the next day.
As the campaign progresses, the shop becomes busier and more systems are introduced. You can rearrange tables and equipment, hire and upgrade Crew, add capacity, unlock new flavors, unlock new equipment, and decide where to spend your resources.
The prototype starts with three ice cream flavors and eventually expands to six. Customers can order cones with 1 to 3 scoops, choosing flavors such as Chocolate, Vanilla, or Strawberry Combo. Those same scoops can also be used to make Shakes, so a small set of ingredients can support a growing number of different orders.
The current campaign spans 21 days across three chapters. The final chapter expands the playable shop and introduces more automation. There is also a persistent currency called Smiles where even a failure is a worthwhile endeavor as it helps level up your Crew.
How we built it
Scoop Days! was built using Codex, with GPT-5.6 Sol and GPT-6 Astra throughout development. Retro Diffusion was used to help create pixel art assets for the game.
The first version was deliberately limited. The shop was essentially a grid of colored squares with labels moving between tiles, which made it easy to focus on whether moving through the shop, serving customers, managing patience, cleaning tables, and changing the layout was actually fun before spending time on artwork.
Working this way made it quick to change rules, move objects, adjust customer timing, remove ideas, and replay the same situations. Once the basic loop started to feel good, I built the visual version on top of it.
From there, the process stayed iterative. I focused first on getting a few days to feel good, getting feedback, and only then extended the progression, added more days, and spent more time on the FTUE. A large part of development kept going back into the same core day loop rather than continually adding features.
Challenges we ran into
The original idea was closer to a bakery with a separate mini-game attached to each product. Interactions were tested, including swiping and swirling to prepare coffee, as well as opening a larger Blender view where ice cream could be dragged into the machine.
Some of these were fun individually, but repeating a separate mini-game for every order became repetitive and pulled attention away from managing the shop, which was becoming the more interesting part of the game.
Preparation was moved back into the shop instead. A Strawberry Shake now uses the same Strawberry scoop that can be used for an ice cream order. The player loads it into the Blender and can do other things while the Shake is getting ready. This creates another decision what should the player work on while the Blender is running? That change helped bring the systems together. More of the complexity now comes from simple actions interacting with each other.
Accomplishments that we're proud of
The game can be understood quickly, but there are still meaningful decisions underneath it. Moving a table a few tiles can shorten a route. Hiring a Busser changes what the player needs to pay attention to. Adding another blender can solve one problem while using resources that could have gone somewhere else.
A ton of attention went into details to make the game feel good, pulsing particles to show where to tap in the FTUE, tooltips to help guide the player, a burst of sprinkles on a home page click. A fun custom scene transition. Custom prompted animations done with care.
The visual feedback also became an important part of the design. Orders show the actual scoops customers want, prepared food appears in the player's hands, dirty tables visibly need attention, and patience is shown where the problem is happening. Most of the work went into making those basic interactions readable and satisfying rather than trying to make the prototype as large as possible.
What we learned
Go slow first, then go fast. Building the first version with almost no art made problems obvious and reinforced how important it was to get the basic game working before adding complexity. If moving squares around a grid was not fun, better graphics were not going to fix it.
A lot of that process came from carefully thinking through prompts, using iterative prompting, and basing development on game feel around the core gameplay first. Each prompt was an opportunity to make a small change, test the result, and decide whether the change improved the experience before moving on.
It also made ideas easier to throw away. The separate food mini-games sounded good on paper, but testing showed that they weakened the larger loop. The process became simple: build the smallest version, play it, change it, and only then invest more heavily in presentation.
What's next for Scoop Stars!
The 21 day prototype introduces new systems and mechanics much faster than a full game would. This is intentional for prototype as it was focused around validating the game loop. Systems should be introduced overtime once the player masters the previous mechanic. The next step is a longer journey, potentially reaching Day 99, with new foods such as sundaes, new stations, deeper Crew progression, equipment upgrades, shop specialization, and more automation.
The progression systems would also receive the same level of testing as the core gameplay. Rather than introducing rewards just to add more systems, the goal is for upgrades and unlocks to create meaningful new choices and give players reasons to keep improving their shop and returning to play over a long period of time.
After the main progression, a separate challenge mode could start the player with an empty shop and the full set of systems available to see how many increasingly challenging days they can survive. The goal is to bring Scoop Days! to Meta Horizon using the new creation tools.
Log in or sign up for Devpost to join the conversation.