"No Ads" became a design constraint
A lot of free mobile games use advertising as part of the gameplay loop: an ad between levels, a rewarded video for another attempt, or a video to obtain an extra resource. Once I decided Aevryn Candy wouldn’t do that, those interruptions disappeared from the design toolbox. That means the game itself has to create the rhythm. A player should be able to open it, play a few levels, enjoy the puzzle, and stop naturally. Optional in-app purchases can exist, but watching an advertisement is never required to continue playing. The broader lesson for me was that monetization choices are also game-design choices. Removing a system can influence the experience just as much as adding one.Difficulty doesn’t have to be a straight line
Once those interruptions were gone, the remaining rhythm had to come from the levels themselves. Balancing progression has been one of the more interesting problems. The obvious approach is to make each group of levels progressively harder. But if the goal is a relaxing game, an endless upward difficulty curve eventually works against that goal. Around level 100, I started experimenting with a different rhythm. On selected groups of levels, I reduce the number of candy colors available, making useful matches easier to find, while keeping harder levels between those groups. Instead of thinking:hard → harder → harder → harderI started thinking:
challenge → breathing room → challenge → breathing roomIt’s a relatively small balancing change, but it has changed the way I think about progression. Difficulty can have pacing just like music or storytelling does.
Change a parameter before inventing another mechanic
When a level or system doesn’t feel right, the developer instinct is often to add something: another booster, another rule, another mechanic. Aevryn Candy has taught me to try the opposite first. The candy-color example is a good illustration. Changing how many colors are present can substantially change the probability of matches, cascades, and available moves. The player experiences a noticeably different level without having to learn anything new. Before adding another system, I now try to ask: can the mechanics that already exist solve this problem? For a small project, that can also mean less UI, less balancing, fewer edge cases, and less maintenance later.Scope is itself a design problem
The same instinct — try the smaller change first — also applies to the project as a whole. It’s easy to keep adding ideas to a game, especially when you’re close to implementation and can imagine dozens of possible features. But every feature has a cost beyond the initial code. It needs presentation, balancing, testing, maintenance, and eventually compatibility with everything that comes after it. So one question has become increasingly useful during development:Does this actually make the puzzle experience better, or am I adding it simply because I can?That question doesn’t mean the game should never grow. It means additions should earn their place.
