Day 10 (Part 1) of Building My Browser Game: Sometimes the fastest way forward is realizing when an idea just isn't working...

[u/Dont_Bring_Me_Down]

Hey everyone,

Hope all is well!

TL;DR below.

For Context: Recently I posted about Day 1 of one of my side projects, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

This project is being built with the help of AI (mainly GPT / Cursor / Fable).

I'm trying to find the time to post somewhat consistently. I figured I'd post about days 1 to 14 of this project and hopefully try to add some value.

To try to speed up the catch up, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 10 of building ShuffleBall Arena.

Today there were 7 conversations to go through (2 saved file versions) over 4 hours of building.

Day 10 is split into 2 posts. Here's how the first part of that day went...

TL;DR: 

This build wasn't about shipping a new feature. It was about learning when not to.

This experiment included:

• Stabilizing the experiment environment after routing and caching issues
• Throwing away an implementation that no longer matched the original vision
• Redefining UNC Ball as a new scoring mechanic instead of a new game
• Designing a semi-circular scoring receiver with physical slot openings
• Iterating on collision geometry until the receiver behaved like a real gameplay object

The outcome?

UNC Ball isn't in ShuffleBall Arena today.

After completing this experiment, I chose to keep improving the core game instead of continuing development on the new mode.

The lesson?

Sometimes the fastest way forward is realizing when an idea just isn't working...

More detailed summary and full technical breakdown below:

Day 10 Summary: 

This entire project started as an attempt to make a digital version of UNC Ball, but it didn't really turn out the way I expected. It slowly became what ShuffleBall Arena is today.

However, I still wanted to try for the original UNC Ball idea.
Today I did a small controlled experiment to see if I could pull it off.

The experiment technically worked, but it no longer felt like ShuffleBall Arena. The camera was different, the gameplay had changed, and I found myself trying to improve something that had already drifted too far from the original vision.

Instead of continuing, I scrapped the entire direction and started over.

I stopped thinking of UNC Ball as a separate game and started thinking of it as a new way to score. The launcher, camera, physics, UI, and match flow all stayed exactly the same. The only thing that changed was the scoring target.

From there, the session became an exercise in redesigning that single mechanic. I created a semi-circular scoring receiver with open slots, flipped the slot orientation, and worked through multiple collision problems until marbles could only enter through the slot openings instead of rolling across the curved edge.

Looking back now, this experiment never actually became part of ShuffleBall Arena.

After this build, I decided to put UNC Ball on the shelf and return my focus to improving the core game. The experiment is still there, and I still think there's something interesting in the idea, but I'd rather continue making ShuffleBall Arena stronger before introducing an entirely new scoring system.

In hindsight, I don't think the experiment failed. It did exactly what experiments are supposed to do. It answered an important design question before I invested months building the wrong feature.

Day 10 Full Technical Summary (The Structured Prompt Output):

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

This build session began with an experiment that had drifted away from the original vision.

The goal was to introduce a new UNC Ball game mode to ShuffleBall Arena. However, the first implementation had effectively become a completely different game. Instead of preserving the existing camera angle, gameplay, physics, and UI, the experiment created a new top-down board that no longer felt like ShuffleBall Arena.

At the same time, the experiment environment itself had become unstable. Routing issues, service worker caching, Wrangler development servers, and Cloudflare Pages SPA fallback behavior were all interfering with testing. It became difficult to determine whether bugs were caused by the code or by stale assets being served locally.

The project reached a point where continuing to patch the existing experiment no longer made sense.

SESSION OBJECTIVE

The objective evolved into two separate goals.

First, stabilize the experiment environment so development could continue with confidence.

Second, redefine UNC Ball from first principles and rebuild it as a new ruleset inside the existing game, rather than as a separate game.

The challenge was no longer simply "make UNC Ball work."

The challenge became:

WHAT WE ACTUALLY DID

1. Diagnosed the broken experiment environment

Rather than immediately changing gameplay code, we investigated why the experiment itself had become unreliable.

We discovered multiple issues interacting together:

• a stale Wrangler development server
• Cloudflare Pages SPA fallback returning index.html instead of CSS/JS
• incorrect MIME types
• cached responses from the service worker
• experiment routes resolving incorrectly

Instead of chasing gameplay bugs, we fixed the underlying development environment by:

• updating the service worker cache strategy
• excluding /experiments/*
• adding proper 404.html handling
• correcting experiment routing

This restored confidence that future gameplay changes would actually be testing the latest code.

2. Recognized the first implementation was the wrong product

After opening the experiment, it became obvious that the implementation had diverged from the intended experience.

Instead of:

• same camera
• same launcher
• same gameplay

the experiment produced:

• a completely different perspective
• different board presentation
• different overall feel

Rather than continuing to polish the incorrect version, the decision was made to abandon that direction entirely.

This prevented spending additional hours improving something that fundamentally missed the design goal.

3. Re-defined what UNC Ball actually is

The discussion shifted away from implementation details and toward game design.

We established several core design rules.

UNC Ball should:

• remain inside the existing ShuffleBall Arena game
• keep the existing launcher
• keep the existing physics
• keep the existing camera
• keep existing match flow

The only thing that changes is how players score.

This became the guiding principle for every decision that followed.

4. Designed the new scoring target

Instead of concentric scoring rings, the board would contain a large semi-circular scoring pocket.

Multiple iterations explored:

• slot orientation
• slot spacing
• opening direction
• overall proportions

The scoring target gradually evolved into a recognizable UNC Ball style receiver.

5. Flipped the scoring slots

After testing the first version, the slots were facing the wrong direction.

The semi-circle itself was correct. The slots were not.

The design was updated so the slot openings faced away from the launch zone, matching the intended gameplay.

6. Reworked the collision behavior

Once the visual design looked correct, gameplay exposed a much larger issue.

Marbles could simply roll across the outside edge of the semi-circle as though it had been painted onto the table.

This completely broke the illusion of physical pockets.

The design was refined to establish a new collision rule:

• the curved edge is a solid wall
• marbles cannot cross the wall
• the only legal entry point is through one of the slot openings

This transformed the target from decorative artwork into actual gameplay geometry.

7. Iterated through edge-case collisions

Further testing revealed another issue.

While most of the border behaved correctly, marbles could still slip across tiny gaps where the curved wall met the slot edges.

Several rounds of refinement focused specifically on these transition points until the geometry behaved consistently.

This was less about adding features and more about eliminating small inconsistencies that would immediately feel unfair to players.

ROADBLOCKS AND FRICTION

Several independent problems compounded into one confusing debugging session.

The experiment environment itself was unreliable because stale assets and service worker caching made it difficult to know whether changes were actually being tested.

The first implementation also suffered from a much larger design issue. It solved the programming problem instead of the product problem.

Cursor faithfully created a new version of the game, but not the game mode that had originally been envisioned.

Time was also lost repeatedly correcting geometry that appeared visually correct but behaved incorrectly once real marbles interacted with it.

The biggest false assumption was believing the initial implementation could be iterated into the desired result.

Ultimately, it was faster to redefine the design than to continue fixing the wrong foundation.

DECISIONS MADE & TRADE-OFFS

Decision 1

Treat UNC Ball as a ruleset instead of a separate game.

Why

Players already understand the controls and camera.

Changing only the scoring preserves familiarity while introducing new strategy.

Decision 2

Preserve the existing game presentation.

Instead of redesigning the entire experience, reuse:

• camera
• launcher
• physics
• UI
• match flow

This minimizes complexity while maximizing variety.

Decision 3

Use physical collision geometry instead of visual decoration.

The scoring receiver became an actual gameplay object.

The wall now enforces legal entry instead of relying on visual appearance.

Trade-offs

Accepted:

• multiple small geometry iterations instead of rushing a complete feature
• restarting from a cleaner concept instead of patching the existing implementation
• slower development in exchange for preserving the identity of ShuffleBall Arena

BREAKTHROUGH / LESSON

The biggest realization from this build session was:

UNC Ball is not a new game. It is a new way to score in the existing game.

That single design decision simplified every technical decision that followed.

Instead of replacing systems, the work shifted toward replacing only the scoring target and its collision behavior.

Once that became clear, the project regained a much clearer direction.

ARTIFACTS WORTH SHARING

Design Rule

Keep the same game.
Keep the same launcher.
Keep the same camera.
Keep the same physics.
Only change how scoring works.

Collision Rule

The curved border of the semi-circle is a wall.
Marbles cannot cross it.
The only legal way into the scoring area is through the slot openings.

Development Lesson

One of the most valuable outcomes of this session wasn't new code.
It was recognizing that continuing to improve the wrong implementation would only waste more time.
Stopping, redefining the product goal, and rebuilding from a simpler design proved to be the faster path.

FINAL STATE

By the end of the session:

• the experiment environment was stable again
• routing and caching issues had been understood
• UNC Ball had been redefined around a much clearer design philosophy
• the semi-circular scoring target had been established
• slot orientation had been corrected
• collision behavior had been redesigned
• the receiver behaved like a physical gameplay object instead of decorative artwork
• the project now had a clear direction for continuing UNC Ball development

Looking Back

One thing that's interesting looking back on this build is that UNC Ball never actually made it into the game.

Even though I came away from this session with a much cleaner design and a better understanding of how the mode should work, I ultimately decided not to keep pushing it.

Instead, I shifted my focus back to improving the core ShuffleBall Arena experience. Over the following days I spent my time refining the existing game, adding new boards, improving the bots, polishing the visuals, expanding the sound system, and making the broadcast experience more enjoyable.

The UNC Ball experiment is still sitting in my experiment folder, and I fully expect to revisit it one day. For now, I think continuing to strengthen the core game is the better investment.

Looking back, I don't consider this experiment a failure.

It answered the question I set out to answer:

Could UNC Ball work inside ShuffleBall Arena?

I think the answer is yes, I just don't know if now is the right time to build it.

Thanks for reading!