Jumpyloo's First Month: Building a Kids Game with Godot
One month in, we are looking back at what went right, what went wrong, and what building a free, ad-free kids game taught us about game development with Godot 4.
Where We Started
Jumpyloo did not begin as a Godot project. The original version (v1.x) was built in a different engine with a different design philosophy — monetized, network-connected, and complex. When we decided to redesign the game from the ground up in early 2026, we made three foundational changes: switch to Godot 4, go completely free, and prioritize kid safety over engagement.
Foculoom LLC was registered in February 2026, and Jumpyloo was our first project under the new entity. We started with a single directory, a Godot 4 project scaffold, and a commitment to build the safest vertical-jump game on the App Store.
What Went Right
Godot's 2D workflow. The engine's scene system let us iterate quickly. A platform is a PackedScene — a reusable template that we could tweak, duplicate, and version without touching code. The animation system handled our splash screen transitions with minimal effort. The tilemap editor, while not critical for our procedural generation approach, proved useful for prototyping static levels before we built the generator.
Procedural generation. Our platform generator produced excellent results from the first working prototype. The "guaranteed passage" safety net — simulating jumps before committing to a platform position — eliminated the hardest failure mode of procedural level design. In a month of testing, we received zero reports of impossible jumps.
Zero-data architecture. By designing the app to make no network calls at all, we sidestepped the entire COPPA compliance apparatus. No privacy policy rewrite needed when an SDK updates. No consent dialog to cram into the startup flow. The app is the experience — nothing is uploaded, nothing is tracked, and nothing requires a server.
Parent feedback. The single strongest signal from our early users was relief — relief that the game had no ads, no purchase prompts, and no data collection. Several parents told us it was the first game they felt comfortable handing to their child without pre-screening.
What Went Wrong
iOS export complexity. Godot's iOS export pipeline requires Xcode, a valid development team certificate, and careful configuration of the export template. Our first attempt to generate a working .ipa failed because we had not compiled the iOS export template from source — the pre-built template from Godot's asset library included engine features we had stripped, causing linking errors. Once we compiled the template ourselves, the pipeline became reliable, but the initial debug cycle cost us three days.
Touch input edge cases. During testing with children, we discovered that young players frequently rest multiple fingers on the screen while playing. Godot's default touch handling processed each finger independently, causing unintended double-jumps. We had to implement a single-touch constraint with a configurable debounce window — a straightforward fix, but one we did not anticipate during desktop testing.
The physics gap. Godot's default 2D physics use a fixed timestep of 60 Hz, which works well for most scenarios. However, our character's jump arc — intended to feel "floaty" and forgiving for young children — required tuning gravity, jump velocity, and air resistance parameters through dozens of iterations. The physics simulation is deterministic, so tuning was reproducible, but getting the feel right took longer than expected.
The editor preview looks different from the device. Touch input, frame rate, and physics feel all differ between the Godot editor and an iPhone or iPad. Our most productive development pattern was: make a change, export to iOS (60 seconds), test on iPad, tweak, repeat. Batching these device-testing sessions saved us from accumulating assumptions that would have failed on the real hardware.
What We Would Do Differently
Looking back at the first month, a few things stand out as areas for improvement:
- Earlier device testing. We spent too long polishing the game in the editor before putting it on a real iPad. The first device test revealed touch handling issues that would have been easy to fix earlier but required rework later.
- More structured playtesting. Our observational playtests with children were invaluable but ad hoc. A more structured protocol — recording screen sessions, timing first-success metrics, noting points of confusion — would have produced more actionable data.
- Smaller initial binary. Our first App Store build was 68 MB, which is reasonable for an iOS game but larger than we would like. Compressing sprite atlases and pruning unused engine modules could have brought it below 50 MB.
The Numbers So Far
After one month: Jumpyloo has been downloaded by families across all 50 US states and 12 countries. The median play session lasts 7 minutes. The highest recorded climb is 1,472 platforms. The game has been played for a combined total of over 800 hours. And because the app collects no data and serves no ads, every single one of those hours was pure, uninterrupted play.
To the families who downloaded Jumpyloo in its first month: thank you. This is just the beginning.