Nymble

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.

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

• animation (frame-based and procedural)

• deployment to the app store

• implementing 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.

Nymble 1 — learning by building

Nymble 1 was my first real game. 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

• UI

• input systems

• animation

• music integration

It was pure iteration — build, break, rebuild.

Nymble 1.1 — rebuilding with intent

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.

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. Instead of improving everything equally, I focused on:

• high-impact UX polish

• interaction clarity

• performance-sensitive design decisions

• more deliberate system architecture

Nymble 2 became less about experimentation and more about refinement.

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.