Nymble

A mobile game I created from scratch

A turn-based puzzle platformer for iOS, designed and built end-to-end from concept to production.

The trailer for Nymble 2 (the sequel), planned for iOS release in 2027.

Nymble is a mobile indie game I built and evolved over multiple years as a solo developer, combining UX design, game development, and orchestral music composition (listen here).

It started as a way to showcase my music skills in an interactive format, but gradually became a full end-to-end playable product spanning all of these disciplines:

UX design (my professional background)
game design and development
orchestral scoring and music production
animation (frame-based and procedural)
app store deployment
level progression analytics tracking
player-driven iteration

The project has evolved through multiple major iterations (Nymble 1 → 1.1 → Nymble 2), including a full rebuild once I had a clearer understanding of game architecture and runtime behavior.

Over time, it gained organic traction, including discovery on Newgrounds and unsolicited player gameplay recordings, which became a core source of real-world UX feedback.

How it all started

A snippet of the opening of Overture from Nymble 2.

I’ve always wanted to compose music for games — not beats or background loops, but full orchestral scores shaped by pacing, tension, and emotional structure. I’m classically trained, so I think about music through harmony, texture, and timbre — using them to express ideas that visuals alone cannot.

The problem was simple: music on its own is hard to show in a portfolio. Most people won’t click a SoundCloud link and sit there listening.

So I built a game to put the music in context.

I chose a puzzle platformer because it was manageable for a solo project, but still flexible enough to support a range of environments and pacing. That gave me room to write and showcase a wide variety of musical styles.

Nymble 1 — learning by building

In 2018, I took it upon myself to learn game programming. After some research, I decide that GameMaker Studio was the right choice, since its proprietary language GML was based on C and Javascript, which I was already familiar with. After some brainstorming, I finally arrived at an idea for a turn-based puzzle platformer with a twist—what if you could jump?

An early state machine I used to map out the player object's states.

At first, the code was messy, but that was the point — I was learning how game systems actually work in practice. The biggest shift was understanding the game loop: games don’t behave like web apps. Everything runs continuously, frame by frame, which changes how you think about state, flow, and interaction.

At this stage, I was experimenting constantly:

mechanics
controls
animation
audio pipeline

Within a week or two, I was programming fairly comfortably in GML.

Nymble 1.1 — rebuilding with intent

📌 Nymble 1.1 marked the first production-ready release, including deployment to the App Store. This required navigating platform guidelines, review processes, and compliance constraints — shifting the project from a personal build to a shipped product.

After learning the fundamentals, I rebuilt the project into Nymble 1.1 — this time with a clear platform strategy. The web version was the primary entry point: instant access, no install, maximum reach. iOS was always the end goal.

That meant the web build couldn’t feel like a prototype. It had to perform well and make a strong first impression.

So the rebuild focused on:

keeping performance tight in the browser
minimizing input lag and frame drops
maintaining enough polish to reflect the intended mobile experience

This directly shaped the architecture — simpler, more efficient systems, designed to hold up under real-world conditions.

🏝️ Vacation sprint development

Throughout this, I was working full-time in UX design, so development happened in focused two-week sprints during vacation periods.

That rhythm forced discipline:

clear scope
realistic goals
meaningful iteration per cycle

It also created distance, which helped me re-evaluate decisions objectively between builds.

Oh and, by the way, here are some "vacation photos" 😎...

Organic traction & real player feedback

Over time, something unexpected happened: players started finding and sharing the game organically. This wasn’t driven by marketing — it was discovery-based. The game was featured on Newgrounds, and received recognition within that community. Players began recording gameplay and sharing reactions without prompting.

That turned Nymble into something more than a vehicle for my music.

I treated this as real research data:

where players hesitated
what they ignored
what they enjoyed unexpectedly
how they interpreted UI and pacing

This feedback loop directly influenced iteration decisions.

At one point, I also had direct communication with Tom Fulp, founder of Newgrounds, who engaged with the project and provided feedback when I explored distribution options outside the platform.

That experience reinforced an important lesson: distribution strategy and product design are tightly linked.

FutureCopLGF played Nymble 2 on Newgrounds and flagged a frustrating level. It revealed that enemy movement and environmental changes weren’t intuitive, so I simplified the setup for better predictability.

Nymble 2 — product thinking and refinement

By the time I started Nymble 2, both my experience and the tooling had evolved significantly. Game engine capabilities were more advanced, and my own thinking had shifted from “how do I build this?” to “where does effort actually improve the player experience?”

This phase was heavily influenced by my UX career and experience working with Product Managers — especially around prioritization and trade-offs.

I also reflected on how Nymble 1 performed in the wild, and started being more intentional about how the game was presented and discovered. That included being deliberate about what was shown in the web demo versus what was held back for the intended iOS experience, as well as treating early marketing decisions as part of the design process rather than something separate.

Instead of improving everything equally, I focused on:

high-impact gameplay polish
optimizing performance for the web demo for a strong first impression
deliberate system architecture
intentional efforts to increase visibility and reach

Nymble 2 became less about experimentation and more about refinement — both in how it plays, and how it is understood.

What I learned

Even after spending hundreds of hours building a fully playable game to showcase my music in context, I realized execution alone doesn’t guarantee attention or evaluation from the industry.

Building the experience is only half the problem — getting it in front of people is the other half. Which is why, with Nymble 2, I’ve started treating product strategy and marketing as part of the design process, not an afterthought.

Final takeaway

I didn’t start Nymble to become a game developer. I started it because I needed a way to prove my music could exist in a real interactive space.

But in the process, I ended up building something else: a full-cycle product that combines UX design, game systems, and orchestral composition — bringing all my core interests into one place.

And now I want to bring that same way of thinking into a studio environment.

Google Sites

Report abuse