Jeremy Johnson's Blog

Designing Daily and Weekly Engagement Systems Mobile game retention depends heavily on creating compelling reasons for players to return daily. The goal: establish a feedback loop where players log in, complete manageable objectives, watch some ads, and feel rewarded—all within approximately 20 minutes. This post covers the systems I implemented to achieve that: daily quests, daily challenge levels, weekly competitive levels, and significant changes to community level creation. Quest System Overview The quest system includes both daily and weekly objectives. Daily quests can be completed in a single session. Weekly quests require sustained engagement—they need 100 points to complete, with individual quests awarding 10 points each, meaning completion takes at least five days of play. Both quest types reward players with chests containing progression resources. Daily Challenge Levels Daily challenges use existing levels from the regular level pool but layer up to three chal...

Separating Ball Effects from Ball Cosmetics This game features a gacha system where players spend gems to acquire ball shards. Collected shards unlock new balls, each with unique visual assets and passive effects. These effects meaningfully change gameplay: modifying the number of level attempts, adjusting ball bounciness, altering ball weight, and more. The challenge was designing a system that lets players leverage these passive effects without forcing them to look at balls they don't want to see during gameplay. The Initial Design Problem My first implementation conflated too many concerns in a single interface. The configuration scene—where players select which balls to use—also contained shard management and upgrade functionality. This created confusion: configuration should be about selecting options, not upgrading them. The solution was to separate these responsibilities. I created a dedicated Upgrade tab where players spend shards to upgrade balls, removing that f...

Xcode Simulator vs. Physical Device: A Costly Lesson in Button Behavior The Xcode Simulator does an excellent job emulating target devices—nearly perfect in most regards. However, relying on it exclusively for validating game behavior is a mistake. There are always subtle differences, and identifying them early prevents significant rework. This post documents a case where I failed to catch a critical issue until six months into development, resulting in a multi-hour remediation effort across hundreds of UI components. Early Indicators: The Subtle Differences Before diving into the main issue, it's worth noting the smaller discrepancies I encountered earlier in the project. These served as early warnings that simulator and device behavior don't always align. Visual Scale Mismatch: During the first two months of development, before I had established a device testing workflow, I was routinely enlarging the simulator window to see my work more clearly. When I finally deplo...