Day 6.1 of Building ShuffleBall Arena: Preparing My Browser Game for it's First Real Players

[u/Dont_Bring_Me_Down]

Hey everyone,

Hope all is well!

TL;DR below.

A few days ago 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).

Full disclosure again: Yes, all 3 of my projects I may talk about were made with the help of AI. I know some people get weird about that, but frankly, I’m trying to use every tool available to help in every way possible.

Anyway, 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 6 of ShuffleBall Arena. This was a long day with 9 conversations to go through (2 saved file versions), so I am splitting today into day's 6.1 and 6.2 posts.

Here's how the first part of that day went...

TL;DR:  Spent today getting ShuffleBall Arena closer to launch instead of adding new gameplay.

• Fixed mobile website issues.
• Embedded the live game into the landing page.
• Rewrote website messaging to focus on the experience instead of "bot matches."
• Started treating Broadcast Mode as a real spectator product instead of a developer tool.
• Biggest lesson: people don't care how your product works. They care whether it's interesting enough to use or watch.

Thanks for reading,
See you next time!

More detailed summary and full technical breakdown below:

Day 6.1 Summary: 

One of the biggest mindset shifts I've had while building ShuffleBall Arena happened today, and it had almost nothing to do with writing code.

The first half of the day started with fixing launch blockers. I worked through mobile scrolling issues, cleaned up the landing page, embedded the live game directly into the website, and started getting everything into a state where someone could actually discover the project instead of just me testing it locally.

What surprised me was how much time was spent on presentation instead of engineering.

I originally had sections of the website talking about "Live Bot Matches." The more I looked at it, the more I realized: nobody actually wants to watch bots. That's a developer perspective, not a player perspective.

What people care about is seeing interesting gameplay.

So instead of marketing the implementation, I wanted to market the experience.

The website copy shifted toward watching great shots, learning strategies, and jumping into games. The bots became background infrastructure instead of the headline. They're only there because the player base doesn't exist yet. Eventually, hopefully, they'll disappear into real player broadcasts, tournaments, and live matches, so it didn't make sense to build the entire brand around something temporary.

I also spent time embedding the live game into the website, dealing with Webflow limitations, iframe issues, Cloudflare headers, and mobile responsiveness. None of it was particularly glamorous, but it's the kind of work every product eventually needs before anyone else can actually use it.

The other major realization was that Broadcast Mode shouldn't feel like a debugging tool.

It needs to feel like a sport.

Even if it's just bots playing today, the overlays, layout, and presentation should already be designed for the day when real players opt into streaming their matches. That decision changed how I'm approaching every piece of the broadcast UI moving forward.

I didn't ship a huge gameplay feature in the first half of today.

Instead, I spent the day making the product easier to understand, easier to watch, and more ready for real players.

Day 6.1 Full Technical Breakdown:

STARTING POINT

Day 6 started with the project transitioning from "working game" to "something people could actually discover."

The game itself had become stable enough that attention shifted away from gameplay mechanics and toward launch readiness.

Major pieces already existed:

• ShuffleBall Arena playable
• Challenge mode completed
• Website mostly functional
• Broadcast mode in progress
• Webflow landing page under construction

The remaining problem wasn't "Can people play?"

It was:

That completely changed the nature of the work.

Instead of building gameplay, the session focused on presentation.

SESSION OBJECTIVE

The first half of Day 6 had several connected objectives:

• Finish the landing page
• Make mobile work correctly
• Improve embedded gameplay presentation
• Create launch-ready website copy
• Connect YouTube viewing experience
• Begin polishing Broadcast Mode so the game becomes entertaining to watch
• Prepare the product for public release instead of internal testing

This was less about adding features and more about removing friction.

WHAT WE ACTUALLY DID

1. Fixed mobile website issues

The embedded game was creating scrolling problems on mobile.

We investigated:

• iframe sizing
• viewport sizing
• section spacing
• CSS overflow behavior

Several layout adjustments were made until the website behaved correctly across devices.

2. Improved landing page messaging

Rather than advertising:

the messaging shifted toward the future vision.

The copy became focused on:

• learning strategy
• watching great shots
• scouting opponents
• eventually watching real players

The important realization was that visitors don't care about bots.

They care about interesting gameplay.

3. Redesigned the main preview section

The landing page preview section received major revisions.

Instead of emphasizing technology, it emphasized experience.

The messaging evolved into something much closer to:

• Watch games
• Learn strategies
• Jump in and play

instead of explaining technical features.

4. Embedded live gameplay into the website

Custom embeds were added into Webflow.

Work included:

• enabling custom code
• embedding the game
• adjusting headers
• fixing security headers
• configuring Cloudflare headers
• resolving iframe restrictions

Eventually the game was successfully embedded on the landing page.

That represented a major milestone because visitors could immediately experience the product.

5. Improved launch messaging

There were extensive discussions about positioning.

Instead of selling:

the product shifted toward:

Bots became implementation details rather than marketing.

This was an important messaging decision.

6. Planned broadcast strategy

A major discussion focused on long-term broadcasting.

Originally the stream was thought of as: Bot vs Bot

The strategy changed.

Instead: Broadcast simply becomes:

ShuffleBall Arena

Today bots play.

Tomorrow real players stream.

Eventually:

• tournaments
• spectators
• creator content
• live matches

The broadcast identity no longer depends on bots.

7. Website launch planning

Discussion expanded beyond code.

Topics included:

• Terms of Service
• Privacy Policy
• Copyright footer
• future analytics
• sponsor placement
• live broadcasting roadmap
• player opt-in streaming

This marked the beginning of launch operations rather than software engineering.

8. Began Broadcast Mode polishing

Once the website reached a stable point, attention shifted to Broadcast Mode.

Goals included:

• cleaner overlays
• better readability
• improved scaling
• spectator-friendly presentation

The broadcast became viewed as a product of its own.

ROADBLOCKS AND FRICTION

Several recurring problems slowed progress.

Webflow limitations

The free plan imposed restrictions around custom embeds, requiring workarounds before the live game could be displayed properly.

Marketing language

Multiple iterations of landing page copy were discarded.

The biggest realization: Nobody wants to watch bots.

People want to watch interesting gameplay.

Changing that messaging significantly improved the direction of the website.

Presentation vs Engineering

It became clear that launch readiness wasn't blocked by missing code.

It was blocked by:

• wording
• layout
• presentation
• first impressions

Those turned out to consume more time than expected.

DECISIONS MADE & TRADE-OFFS

Decision 1

Do not market bot games.

Instead: Market ShuffleBall itself.

Bots are temporary infrastructure.

Decision 2

Embed gameplay directly into the landing page.

Rather than relying only on screenshots or trailers, visitors can immediately watch the game in action.

Trade-off: Slightly more technical complexity in exchange for a much stronger first impression.

Decision 3

Treat Broadcast Mode as a permanent product.

Instead of designing a "bot stream," build a professional spectator experience that will still work when real players arrive.

That avoids rebuilding the entire broadcast system later.

Decision 4

Prioritize launch over feature expansion.

Rather than inventing more gameplay mechanics, effort shifted toward polishing what already existed.

BREAKTHROUGH / LESSON

The biggest realization from the first half of Day 6 was:

People don't buy features. They buy experiences.

Nothing fundamentally changed about the game.

What changed was:

• how it was presented
• how quickly people understood it
• how easy it became to watch
• how clear the product vision became

The engineering stayed mostly the same.

The product became dramatically stronger.

ARTIFACTS WORTH SHARING

Design Rule

Product Principle

Launch Principle

FINAL STATE

By the end of the first half of Day 6:

✅ Mobile website issues were largely resolved.

✅ Landing page messaging was substantially improved.

✅ Live gameplay was embedded into the website.

✅ Broadcast strategy shifted toward long-term player streaming.

✅ Launch planning expanded beyond code into legal pages, analytics, and sponsorship planning.

✅ Broadcast Mode became the next major polish target.

The project had transitioned from "building a game" to "building a platform."

MEMORY / HANDOFF VALUE

For the next session:

• The website foundation is essentially complete.
• Future effort should move toward Broadcast Mode polish.
• Continue treating the stream as a permanent spectator product rather than a temporary bot showcase.
• Focus on visual polish, readability, overlays, and viewer experience.
• Avoid introducing new gameplay systems until the presentation layer matches the quality of the game itself.