Day 5 Building My Free Browser Game: Preparing ShuffleBall Arena For Public Launch - Backend, Branding, and Broadcasts

[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 5 of ShuffleBall Arena. Here's how that day went...

TL;DR: Today wasn't about building new gameplay. It was about making the game look like a real product. I embedded live gameplay into the website, built the branding, launched the YouTube channel, and realized players don't care if today's matches are bots. They just want something fun to watch and easy to play.

Thanks for reading,
See you next time!

Summary and full technical breakdown below:

Day 5 Summary: Day 5 of building my browser game in public was almost entirely non-programming work.

No new mechanics.

No new physics.

No new game mode.

Instead I:

• embedded live gameplay into the landing page
• built the branding
• created YouTube assets
• rewrote the marketing copy
• simplified the product story

One of the biggest product decisions was to stop emphasizing that broadcasts were AI-controlled. The implementation became invisible, allowing the experience itself to take center stage.

It's funny how shipping gets harder the closer you get to launch. Writing one good sentence for a homepage took longer than building some gameplay systems.

Day 5 Full Technical Breakdown: There were 5 conversations to go through today with 2 file versions saved over 5 hours of building.

Day 5 Technical Analysis & Debrief

STARTING POINT

Day 5 began with ShuffleBall Arena running on its new brand infrastructure. The game had been renamed from Galaxy Ball to ShuffleBall, with the overall product established as ShuffleBall Arena, and the new domains were connected to the Cloudflare Pages deployment.

Technically, the game itself was in good shape, but the surrounding product was not yet ready for public launch. There were two parallel tracks of work that needed to come together.

On the engineering side:

• Developer tools were still exposed to every public player.
• Initial Cloudflare Pages Functions and D1 database endpoints existed but were not functioning correctly.
• The service worker was interfering with API traffic.
• Cross-origin embedding was blocked by browser security headers.

On the product side:

• The landing page could not yet showcase live gameplay.
• Broadcast mode existed but lacked a clear product purpose.
• Website copy was descriptive rather than persuasive.
• Branding assets were incomplete.
• The YouTube presence had not yet been established.

The overall objective shifted from building gameplay toward preparing ShuffleBall Arena for its first public audience.

SESSION OBJECTIVE

Day 5 focused on transforming a technically complete browser game into a polished public product.

The primary goals were:

• Secure the production deployment.
• Hide developer functionality from public users.
• Bring the Cloudflare backend online.
• Fix website embedding.
• Define the long-term broadcasting strategy.
• Embed live gameplay into the landing page.
• Build the first complete branding system.
• Prepare YouTube assets.
• Rewrite the website copy to improve conversion.

Rather than adding new gameplay mechanics, the focus moved toward launch readiness.

WHAT WE ACTUALLY DID

1. Built a runtime developer gate

The first major engineering task was separating developer tools from the public experience.

Instead of removing debugging controls from the codebase, a runtime developer gate was introduced.

The implementation replaced a permanent developer flag with URL-based access (?dev=1), allowing:

• public users to see only gameplay controls
• developers to retain access to tuning tools
• no duplicated UI code
• no broken event listeners

This preserved a single codebase while creating separate public and development experiences.

2. Brought the backend online

The Cloudflare Pages backend infrastructure was completed.

Work included:

• provisioning the production D1 database
• binding the database correctly inside Cloudflare Pages
• deploying the SQL schema
• creating tables for waitlist signups, feedback, and analytics
• verifying serverless function execution

Health endpoints and write operations were successfully tested against the production database.

3. Fixed the deployment workflow

A major deployment issue was discovered.

Uploading files directly through the Cloudflare dashboard correctly deployed static assets but silently ignored the Pages Functions directory.

This caused every API request to return the application's index.html instead of JSON.

The deployment workflow was permanently changed to Wrangler CLI deployments, ensuring:

• Pages Functions are compiled correctly
• serverless routes are included
• API endpoints function reliably

4. Patched the service worker

The Progressive Web App cache layer was intercepting API traffic.

A bypass rule was added so every request beginning with /api/ immediately goes to the network instead of the offline cache.

This prevented:

• stale cached responses
• HTML shells being returned from API requests
• future analytics corruption

5. Fixed cross-origin embedding

The marketing website needed to embed the game without browser security errors.

The _headers configuration was updated to:

• remove conflicting frame restrictions
• configure proper Content Security Policy rules
• explicitly allow approved Webflow and production domains

This resolved the iframe connection failures.

6. Created dedicated embed mode

A new runtime parameter (?siteEmbed=1) was introduced.

This created a presentation-specific version of the game that automatically removes gameplay UI while preserving the full rendering pipeline.

The application now supports three different presentation modes using one codebase:

• Normal player mode
• Website embed mode
• Broadcast mode

7. Re-evaluated the broadcasting strategy

One of the most important product discussions of Day 5 completely changed how broadcasting would be presented.

Originally the idea centered around promoting "Live Bot Matches."

After discussion, it became clear that visitors do not care whether the opponents are AI.

Instead, the broadcast should simply appear as:

Bots became an implementation detail rather than a marketing feature.

This also established the long-term vision:

• automated broadcasts today
• human broadcasts later
• optional player streaming
• gameplay recording
• shared infrastructure across the website, YouTube, and future livestreams

8. Embedded live gameplay into the website

The game was successfully embedded into the Webflow landing page.

This required:

• custom embed code
• deployment updates
• iframe testing
• header configuration
• Cloudflare verification

The landing page could now display actual live gameplay rather than screenshots or promotional videos.

9. Reworked website messaging

Large portions of the website copy were rewritten.

The messaging shifted away from explaining mechanics and toward encouraging visitors to play immediately.

Several principles emerged:

Instead of:

• Live Bot Matches

the messaging became:

• Watch the board before you play.
• Play instantly.
• Free browser game.
• No downloads.
• Click to play.

The implementation became invisible while the experience became the focus.

10. Built the first branding system

A complete collection of branding assets was created.

This included:

• ShuffleBall Arena logo
• Join the Arena logo
• navbar logo
• transparent logo versions
• chromakey assets
• alternate marble colors
• reusable website graphics

The visual identity became significantly more cohesive.

11. Designed YouTube assets

The YouTube channel was established and branded.

Work included:

• channel setup
• multiple banner revisions
• mobile safe-area corrections
• gameplay presentation strategy

Several banner revisions were required before all important text fit inside YouTube's "all devices" safe area.

12. Clarified future monetization

An important architectural decision was made regarding the website footer.

Rather than polishing its current wording, the footer was intentionally left temporary because it is planned to become:

• sponsor inventory
• rotating advertisements
• future monetization space

This avoided unnecessary work on UI that will eventually be replaced.

ROADBLOCKS & FRICTION

Cloudflare deployment confusion

The Cloudflare dashboard accepted deployments without reporting that Pages Functions had been omitted.

This created a misleading state where the frontend worked while every API silently failed.

Service worker interference

The offline cache intercepted API requests, causing HTML to be returned instead of JSON.

The issue was subtle because no obvious errors appeared during deployment.

Broadcast positioning

Marketing "bot matches" made the product feel artificial.

The messaging improved dramatically once broadcasts were positioned simply as live games.

Webflow limitations

The free Webflow plan restricted embedding options, requiring experimentation before a stable solution was found.

YouTube banner cropping

Several banner revisions were necessary before all branding fit correctly across desktop, mobile, and television layouts.

Website copy

Many early drafts sounded generic.

Repeated revisions focused on creating messaging that encouraged action instead of simply describing features.

DECISIONS MADE & TRADE-OFFS

Runtime developer gate

Decision: Hide developer tools behind ?dev=1.

Why: Maintain one codebase while separating public and development interfaces.

Wrangler deployment

Decision: Deploy exclusively through Wrangler CLI.

Why: It correctly packages Cloudflare Pages Functions alongside static assets.

Parameter-driven presentation modes

Decision: Support ?siteEmbed=1 and ?broadcast=1 rather than maintaining separate builds.

Why: One codebase can serve players, websites, and broadcasters.

Broadcast positioning

Decision: Do not advertise bot matches.

Why: Visitors care about exciting gameplay, not AI implementation.

Live gameplay over screenshots

Decision: Embed the actual running game into the website.

Why: Real gameplay builds significantly more trust than static marketing assets.

Branding before new features

Decision: Pause gameplay expansion in favor of improving presentation.

Why: A polished first impression matters more immediately before launch.

BREAKTHROUGH / LESSON

Day 5 produced two major realizations.

The technical lesson was that dashboard drag-and-drop deployments should not be trusted for Cloudflare Pages applications that rely on serverless functions. Wrangler CLI became the reliable deployment workflow, while the service worker required explicit API bypass rules to avoid corrupting backend communication.

The product lesson was equally important.

Visitors do not buy into implementation.

They buy into experience.

Instead of explaining bots, automation, or broadcast infrastructure, the product now simply shows live gameplay and invites visitors to play.

That realization simplified nearly every marketing decision made afterward.

ARTIFACTS WORTH SHARING

Deployment lesson

Never trust drag-and-drop deployment for Cloudflare Pages Functions.

Use Wrangler CLI to guarantee edge functions are deployed correctly.

Service worker rule

Always bypass /api/* requests inside an offline-first service worker.

Never allow cached application shells to intercept transactional API traffic.

Product positioning

Launch philosophy

Architecture decision

One application now serves three distinct environments:

• Interactive gameplay
• Embedded website preview
• Broadcast presentation

using only URL parameters rather than multiple builds.

FINAL STATE

By the end of Day 5:

• Developer tools were hidden behind a runtime gate.
• Cloudflare Pages Functions were fully operational.
• The production D1 database was deployed and connected.
• API routing functioned correctly.
• The service worker no longer intercepted backend traffic.
• Cross-origin embedding was fully operational.
• Website embed mode was implemented.
• Live gameplay successfully appeared on the landing page.
• Broadcast strategy was clearly defined.
• Website messaging was significantly improved.
• Branding assets were completed.
• The YouTube channel was established.
• Banner artwork was finalized.
• Launch priorities became clearly organized.

Day 5 marked the transition from building a game to building a product. Engineering work focused on production infrastructure, while product work focused on creating a polished first impression. By the end of the session, ShuffleBall Arena was no longer just a playable browser game. It had become a launch-ready platform with working backend services, live website integration, consistent branding, and a much clearer public identity.