Growing feels good. But if the next stage arrives almost as soon as the last one, the player gets little time to live at the new size. They haven’t figured out what they can eat now, and the meter is already preparing another change. In Guzzle Boom!, we had to consider the pace of growth separately from the pleasure of getting bigger.
The first idea had a huge appetite: build up speed and evolve from slime into a galaxy eater. The prototype quickly showed the downside. Super speed can eat up readability before the hero eats anything interesting. And if you simply take away the speed, fun doesn’t necessarily take its place. We tried both extremes and looked for a middle ground.
In a September tuning pass, we switched to doubling the cost of each successive stage. The meter still showed the familiar progress from zero to one hundred percent, but it represented more and more food. We made this change after a request to make growth less frequent.
The same meter, a longer distance
Early steps introduce the rule. Later ones require you to keep an attempt going longer: find food, avoid hits, and use the abilities you’ve already earned. The screen doesn’t need to show huge numbers for growth to slow down. But the player should feel that the next stage now takes more actions.
This was a working pace setting, not proof that the difficulty was right. We could check the formula automatically: food adds the right amount, the threshold is calculated correctly, and progress is saved. Whether the stretch between growth stages is enjoyable for a person has to be found out in the game. These questions are connected, but they need different answers.
Later, feedback from friends helped us see the game from the outside. Some of the mixed reactions included a sense of boredom. We can’t honestly conclude that one growth formula was to blame: some people struggled with the interface, while others couldn’t figure out the skills. But it became clear that adding content and making a game more interesting aren’t always the same thing. We had to think about the depth of the microworld itself, not only how quickly the player flies past it.
Growth and the boss encounter
Another question came up at the same time: when would the boss appear? In that version, the encounter was tied to three minutes of flight time. Pauses and choosing mutations didn’t count toward that time. If you counted ordinary minutes at the screen, the wait could feel longer.
We added a persistent countdown. This changed how the wait was explained; it didn’t shorten it. Players could now see how much flight time remained and compare the growth meter with the approaching boss. The two processes no longer looked like one confusing queue of rewards.
We don’t rewrite an attempt already in progress
The pace change applied to new attempts. Attempts already underway kept their existing rules. Otherwise, after loading a save, a player could suddenly find that the next growth stage required a different amount of food, even though they hadn’t done anything.
These transitions rarely become the most noticeable part of a devlog. But they’re part of what builds trust: the game remembers not only the hero’s position, but also the rules of that attempt. We want an experiment with pacing to avoid becoming an unexplained penalty for the player. Growth can become slower; the reason for the change should stay clear during development and after returning to a saved game.
