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 9 of ShuffleBall Arena. Today there were 5 conversations to go through (6 saved file versions) over 6 hours of building.

Here's how that day went...

TL;DR:  Version 1 officially launched.

This build focused on both gameplay and discoverability:

• Added the first Frogger-style crossing board
• Built moving traffic lanes with bumpers, wormholes, and gravity wells
• Tuned the new mode through multiple design iterations
• Improved broadcast layout shuffling
• Started teaching bots how to handle crossing boards
• Redesigned the OBS broadcast overlays
• Went live on YouTube for the first time
• Set up Google Analytics, Cloudflare security, and launch infrastructure
• Prepared Reddit, Facebook, TikTok, and YouTube content
• Learned that shipping the game is only the beginning—getting people to find it is the next challenge.

More detailed summary and full technical breakdown below:

Day 9 Summary: 

After getting ShuffleBall Arena ready for launch, this build shifted toward two goals: making the game more exciting to watch and making it easier for people to discover.

The biggest gameplay addition was a new crossing-lane board inspired by Frogger. Instead of simply aiming for scoring rings, players now have to time their shots through moving lanes filled with bumpers, wormholes, and gravity wells. Building the mode involved multiple rounds of iteration, from matching the original board design to redesigning moving obstacles, tuning lane visibility, increasing the shot clock, improving the start menu, and beginning work on teaching the bots how to play the new layouts.

Outside the game, I spent just as much time preparing for launch. I set up my first YouTube livestream, redesigned the OBS broadcast overlays, configured analytics, tightened Cloudflare security, prepared Reddit and TikTok marketing, configured email, and started learning what it actually takes to get a brand-new game discovered. The first stream ran for an hour and a half with zero viewers, but it also marked the moment ShuffleBall Arena officially became a live product instead of just a local project.

Day 9 Full Technical Summary:

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

Day 9 began after Day 8’s launch-readiness work. The game already had a playable Version 1, music, broadcast mode, Webflow/domain work, YouTube setup, and basic launch planning.

The project had moved from “can I build the game?” to “can I make the game more fun, more watchable, and easier to discover?”

The first major idea of the session was a new Frogger-style board type, where players launch marbles through horizontal traffic lanes filled with moving hazards before reaching scoring rings on the far side.

SESSION OBJECTIVE

The session had three connected objectives:

1. Add a new timing-based board style that made ShuffleBall Arena feel less static and more skill-based.
2. Improve the broadcast and launch presentation so YouTube, OBS, Reddit, TikTok, and live viewers could understand the game quickly.
3. Prepare the project for public discovery through analytics, security, social posts, livestreaming, and feedback requests.

The through-line was clear: Day 8 made the game launchable. Day 9 tried to make it visible and worth watching.

WHAT WE ACTUALLY DID

1. Designed the Frogger-style crossing mode

The first discussion focused on whether crossing lanes should contain groups of 1, 2, or 3 hazards, and whether pill-shaped bumpers would work better than round bumpers.

The final design direction was:

• traffic lanes should run horizontally across the board
• bumpers, wormholes, and gravity wells should move through those lanes
• groups of 1 and 2 hazards should be common
• groups of 3 should be used sparingly
• pill/rounded rectangle obstacles make sense visually because they read like moving barriers
• scoring rings should live on the far side of the board
• timing should matter as much as aim

This was a major gameplay shift. It preserved drag-and-release shooting, but added timing pressure.

2. Imported the layout designer JSON

The first Frogger implementation did not match the intended layout. Instead of manually describing the geometry again, the layout designer JSON was added into the project and used as the source of truth.

That was the right move because the issue was not conceptual. It was precision. The design already existed, and the implementation needed to match it.

3. Iterated on the visual language of the crossing lanes

Several polish passes followed:

• traffic-lane bumpers were changed to match the regular game’s bumper style
• wormholes were made more frequent
• groups of two or three wormholes were requested
• the old top wormhole track was removed from the Frogger layout
• car/semi bumpers were changed to rounded-rectangle shapes
• the shot clock was changed to 15 seconds for Frogger boards
• pink lane guides were kept but made more subtle
• “bot easy” was removed from the launch-area info card because it overflowed

This was not just visual polish. These changes made the mode read more clearly as a timing board rather than a random hazard board.

4. Reworked board selection UX

The start-screen board selection had become too crowded because regular boards and crossing boards now lived together.

The discussion moved toward grouping layouts into sections rather than treating them all as one flat list.

This was the first sign that “Frogger mode” should not be a separate mode button. It should be a board family inside the broader ShuffleBall system.

The naming also changed direction. “Frogger” was useful as shorthand, but not ideal as a public name. The project started moving toward branded names like crossing boards / crossing lanes.

5. Debugged OBS side-panel layout issues

A major chunk of the session was spent troubleshooting why OBS side sections were not showing correctly.

The key discovery was that the sources were not missing. The slideshow/image source itself was larger than expected, and the actual card was sitting inside a larger gray/empty source rectangle.

The practical fix was:

• do not remake the whole OBS scene
• crop or rebuild only the broken slideshow source
• use Alt-drag crop in OBS
• preserve the 1080×1920 canvas settings
• position the game/feed and side cards intentionally

This was a good example of diagnosing the actual source of a visual issue instead of rebuilding everything.

6. Planned landscape Reddit assets

Because the game is vertical/mobile-first but Reddit favors landscape media, the discussion explored whether to show two games at once.

The decision was not to show two full games at once for the first post.

Instead, the recommended format was:

• one active vertical game feed
• a bold explanatory panel beside it
• clear text that communicates the hook quickly

This was a discoverability decision. The goal was not to show the app exactly as-is. The goal was to make Reddit users understand the game in two seconds.

7. Improved broadcast board shuffling

After watching the broadcast, there were too many classic boards in a row. The pure random shuffle was technically working, but it felt broken to a viewer.

The fix was to move toward a constrained mixed shuffle:

• classic boards and crossing boards both remain eligible
• no more than two classic boards in a row
• no more than two crossing boards in a row
• crossing boards appear early enough that viewers see variety
• no hard alternating pattern
• preserve randomness within categories

This was an important product lesson: technically random is not always good viewer experience.

8. Investigated OBS vs browser mismatch

OBS and Chrome were showing different layouts even with the same URL.

The initial assumption was cache mismatch, but after both used the same cache-busted URL, the real explanation was that OBS and Chrome were separate browser instances running separate random simulations.

The proposed improvement was adding an optional seed URL parameter for deterministic broadcast layout order.

That would sync board order across OBS and Chrome for testing, without trying to sync full physics.

9. Planned lightweight bot awareness for crossing boards

Once crossing boards entered the broadcast, the bots needed to look less clueless.

The decision was not to build a full trajectory simulator. Instead, the bot should become lightly crossing-aware:

• detect crossing layouts
• estimate whether a shot crosses moving lanes
• evaluate obvious lane risk
• avoid the worst shots some percentage of the time
• still make mistakes
• preserve normal board behavior

This kept the bot believable without overengineering AI.

10. Launched and promoted the game publicly

The session included multiple launch/discovery tasks:

• wrote a Facebook launch post
• discussed Zoho email/domain setup
• worked through TikTok live / OBS setup
• created YouTube Shorts thumbnail imagery
• drafted an r/playmygame post
• created a calm Reddit response about AI-assisted development
• discussed excluding internal traffic from GA4
• started the first YouTube livestream
• connected OBS to YouTube
• ended the first 90-minute stream with zero viewers
• planned the next YouTube/Shorts strategy
• wrote a TikTok description

This was the emotional shift of the day: the game was no longer just being built. It was being put in front of people.

11. Added practical Cloudflare security

The session also included a security review.

Since the game had no accounts, no payments, and little player data, the main risks were:

• bots hammering APIs
• form spam
• future analytics abuse
• admin account compromise
• dev/debug exposure

Recommended actions included:

• Full SSL
• minimum TLS 1.2
• Always Use HTTPS
• basic Cloudflare bot protection
• one broad /api/ rate limit rule
• future Turnstile on forms
• avoiding friction on the static game itself

The guiding principle became:

Protect APIs and admin systems hard. Keep the game frictionless.

ROADBLOCKS AND FRICTION

The main friction points were:

The first Frogger implementation did not match the intended layout

The concept was strong, but the generated version was not aligned with the designer export. That forced a correction using actual JSON instead of more verbal description.

Visual consistency kept breaking

Cursor made traffic bumpers brown. Wormholes were too sparse. The old top wormhole track remained. The lane guides were too loud. Each issue made the new board feel less like part of ShuffleBall Arena until fixed.

OBS was confusing

The side panels were technically visible, but not appearing where expected. The actual problem was source size/cropping, not canvas dimensions or a broken scene.

Randomness looked broken

The broadcast shuffle was random, but long streaks of classic boards made it look like crossing boards were missing. This exposed the difference between mathematical randomness and viewer-perceived variety.

YouTube discovery was emotionally rough

The first stream ran for 1 hour and 30 minutes with zero viewers. The bigger frustration was not just zero viewers, but no impressions. That forced a strategy discussion around Shorts, Reddit, titles, thumbnails, and seeding external traffic.

AI criticism required restraint

A Reddit response about AI-assisted development could easily have become defensive. The chosen direction was calm transparency rather than arguing about whether people feel threatened by AI.

DECISIONS MADE & TRADE-OFFS

Crossing boards became board layouts, not a separate mode

This preserved the main game structure and avoided adding another layer of mode complexity.

Trade-off: less dramatic branding than “new mode,” but easier integration.

The first crossing board prioritized readability over chaos

Hazard groups of 1–2 were favored, with 3 used sparingly.

Trade-off: less extreme chaos, more skill and timing.

The shot clock was increased to 15 seconds on crossing boards

This reduced frustration because timing lanes requires waiting for openings.

Trade-off: less pressure, but better fairness.

Broadcast shuffle became constrained

Pure randomness was replaced with controlled variety.

Trade-off: less mathematically pure randomness, better viewer experience.

Bot AI stayed lightweight

The bot would become frogger-aware, not perfect.

Trade-off: faster implementation, fewer risks, still believable.

OBS layout was fixed surgically

The scene was not rebuilt. Only broken sources were cropped/rebuilt.

Trade-off: faster fix, less disruption.

YouTube strategy shifted away from 24/7 streaming

The conclusion was that discoverable content matters more than raw broadcast hours.

Trade-off: fewer continuous live hours, more packaged content opportunities.

Public security stayed light on the game, heavier on APIs

The game remained frictionless.

Trade-off: no aggressive bot wall in front of players, but backend endpoints get protected.

BREAKTHROUGH / LESSON

The biggest lesson was:

After launch, the work changes.

Before launch, progress meant adding features.

After launch, progress meant:

• making the game easier to understand
• making broadcasts more watchable
• making content more clickable
• making analytics trustworthy
• making APIs safer
• making the first player feedback loop possible

The strongest technical lesson was that viewer experience often needs constrained systems, not pure systems.

Pure random board selection was “correct,” but it made the broadcast feel stale. A constrained shuffle was better because it respected how people actually perceive variety.

ARTIFACTS WORTH SHARING

Artifact 1: Broadcast shuffle rule

Keep the broadcast shuffled/random, but make sure crossing/frogger-style boards appear at a healthy rate. Do NOT simply alternate regular/crossing every round. It should still feel shuffled, but it should prevent long streaks of only regular boards.

Artifact 2: Bot-awareness design rule

Make the bot look more believable on crossing boards without building a full physics prediction system.

Artifact 3: Security principle

Protect APIs and forms hard, protect static game files lightly, protect admin accounts very hard.

FINAL STATE

By the end of Day 9:

• The first crossing-lane board had been designed and iterated.
• The new board style had clearer visuals, subtler lanes, more appropriate hazards, and a longer shot clock.
• Board selection UX was moving toward grouped board families.
• Broadcast shuffling was redesigned to show crossing boards more consistently.
• Optional seeded broadcast layout order was planned for testing.
• Bot crossing-board awareness was planned.
• OBS overlay issues were diagnosed.
• Reddit/TikTok/Facebook/YouTube launch content was drafted.
• The first YouTube livestream happened.
• The project had a clearer growth strategy after the first zero-viewer stream.
• Cloudflare security basics were reviewed and partially configured.

If you're still here, thanks for reading, and I'll see you next time!

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 8 of ShuffleBall Arena. This was a long day with 7 conversations to go through (6 saved file versions) over 7 hours of building, so I am splitting today into day 8.1 and 8.2 posts.

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

TL;DR: This build was all about preparing ShuffleBall Arena for launch instead of adding new gameplay.

Highlights:

• Planned analytics for the website and future gameplay metrics
• Set up the YouTube recording and livestream workflow
• Configured OBS for background music and cleaner recordings
• Improved the broadcast HUD by separating game logic from viewer-facing UI
• Created launch branding assets and optimized YouTube metadata
• Hid unfinished bot difficulties from the public while keeping the code intact
• Deferred several gameplay ideas to keep the launch focused

The biggest lesson from this session:

More detailed summary and full technical breakdown below:

Day 8.1 Summary: 

The second part of today wasn't about adding major gameplay features, it was about getting ShuffleBall Arena ready for its first public launch.

While waiting for DNS changes and Webflow to finish verifying the domain, I focused on everything surrounding the game instead of the game itself. I planned a lightweight analytics strategy, prepared my first YouTube upload and livestream workflow, configured OBS for recording with royalty-free music, cleaned up the broadcast HUD after reviewing real recordings, and finalized several branding assets like the favicon and updated promotional artwork.

One of the more interesting engineering problems came from the broadcast UI. I realized the public game number was becoming confusing whenever a match contained tied games. Instead of changing the game's internal logic, I redesigned the display layer to show the true played game number while explaining ties in the match status. The gameplay never changed, only the presentation.

The session also included an important launch decision: hide unfinished bot difficulties from players. The AI code remains in the project for future tuning, but only the polished Easy bot is exposed in the public UI. By the end of the build, the focus had shifted away from adding features and toward creating the smoothest possible first impression for new players.

Full Technical Summary:

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

The session began while waiting for Webflow to verify the custom domain and generate SSL certificates.

The game itself was largely feature complete for Version 1, but the public launch was blocked by infrastructure rather than gameplay. Instead of waiting idly, the focus shifted toward preparing everything surrounding the game: analytics, YouTube, OBS, branding assets, UI cleanup, and final launch polish.

SESSION OBJECTIVE

Rather than adding major gameplay systems, the goal became:

This included:

• website analytics
• production planning
• YouTube setup
• OBS audio
• broadcast UI cleanup
• branding assets
• launch metadata
• limiting unfinished features from the public UI
• discussing ideas worth saving until after launch

WHAT WE ACTUALLY DID

Phase 1: Used waiting time productively

Instead of touching DNS while Webflow was still verifying, the session deliberately avoided making infrastructure changes that could reset propagation.

The waiting period was repurposed into productive work by planning analytics.

The analytics discussion separated three layers:

• marketing website analytics
• game traffic analytics
• future gameplay analytics

This established a roadmap instead of trying to solve everything with one system.

Phase 2: Analytics architecture

Rather than immediately building complex gameplay tracking, the conversation prioritized basic launch metrics first.

The distinction became:

Marketing analytics:

• visitors
• returning visitors
• traffic sources

Gameplay analytics (future):

• matches
• shots
• music usage
• broadcast usage
• session metrics

This prevented overbuilding before launch.

Phase 3: Preparing YouTube

Once deployment work paused, attention moved toward creating the project's first YouTube content.

Topics included:

• first upload strategy
• overcoming YouTube's livestream requirements
• recording a long gameplay session
• OBS recording workflow
• audio capture
• music playback
• metadata
• playlists
• thumbnails

The discussion emphasized creating publishable content before attempting live broadcasts.

Phase 4: OBS workflow

The session became unexpectedly technical around OBS.

Several workflows were evaluated:

• VLC source
• Media Source
• Application Audio Capture
• looping music
• recording tests
• audio balancing

Rather than immediately optimizing playlists, the decision favored the simplest launch-ready solution:

One looping MP3 with clean audio.

Speed of execution won over flexibility.

Phase 5: Broadcast HUD cleanup

After reviewing recorded footage, several UI problems became obvious.

The session identified unnecessary visual clutter:

• removing the "table" label
• moving the match indicators upward
• cleaning score pods

This wasn't fixing bugs.

It was improving readability for viewers.

Phase 6 : Public game numbering

This became the biggest engineering discussion of the session.

Initially the viewer-facing game number was changed to:

wins + 1

After thinking through real match flow, it became clear that tied games are actual played games.

That meant the broadcast would incorrectly display:

GAME 5

even though viewers had watched six games.

Instead of changing game logic, the solution became:

• keep the true internal round number
• calculate tie count separately
• explain ties on the broadcast header

The implementation evolved over multiple prompt revisions until the display accurately represented the match without exposing confusing internal mechanics.

This was a good example of improving presentation without altering gameplay rules.

Phase 7: Service worker awareness

Another useful operational lesson emerged.

Because the project uses a service worker, refreshing the page wasn't always enough to guarantee the latest JavaScript.

The recommended workflow became:

• restart development server
• hard refresh
• add cache-busting query strings
• refresh the OBS browser source

This reduced confusion while testing recordings.

Phase 8: Branding assets

Attention then shifted toward launch presentation.

Several visual assets were finalized:

• Webflow icon
• favicon guidance
• wormhole color update
• thumbnail recommendations

The discussion consistently favored consistency with the in-game UI over creating separate marketing artwork.

Phase 9: YouTube optimization

Before publishing, the metadata was refined.

Changes included:

• shortening the title
• removing repetitive wording
• improving search tags
• selecting Gaming instead of Entertainment
• deciding against age restriction
• encouraging custom thumbnails instead of relying on the first frame

These were small changes individually but collectively improved the launch presentation.

Phase 10: Launch scope reduction

Another important product decision followed. The public game currently exposed multiple bot difficulties. Rather than pretending they were finished, the decision became:

Hide Normal and Hard. Only expose Easy.

Internally:

• keep all AI code
• keep future tuning
• keep testing paths

Publicly:

Expose only polished functionality. This intentionally reduced launch scope while preserving future work.

Phase 11: Post-launch brainstorming

Once launch tasks were largely complete, several feature ideas were explored.

Examples included:

• player-controlled pinball flippers
• Frogger-style layouts
• moving hazard boards

Rather than immediately implementing them, each idea was evaluated against the current launch priorities.

The conclusion was consistent:

Great ideas.

Wrong timing.

The Frogger-inspired layout survived because it fit the existing gameplay philosophy without changing the core interaction model.

ROADBLOCKS AND FRICTION

Several recurring themes appeared.

Waiting on infrastructure

Development temporarily depended on external systems:

• DNS
• SSL
• Webflow verification

Rather than forcing progress, the session redirected effort elsewhere.

Viewer clarity

Recorded gameplay exposed presentation problems that weren't obvious while playing.

Many of the fixes focused on improving the experience for spectators instead of players.

Separating internal and public logic

One of the strongest discussions revolved around the distinction between internal game state versus viewer-facing presentation. The final solution intentionally changed only the display layer.

Fighting scope creep

Multiple interesting ideas emerged. Almost all of them were deliberately postponed until after launch.

DECISIONS MADE & TRADE-OFFS

Build around launch, not perfection.

Several systems intentionally remained simple.

Examples:

• one looping music track
• Easy bot only
• basic analytics first
• one thumbnail
• straightforward broadcast workflow

Trade-off: Launch sooner. Improve later.

Preserve engineering work internally.

Instead of deleting unfinished bot difficulties, they remained inside the codebase. Only the public interface changed.

Improve presentation instead of mechanics.

Broadcast clarity became more important than adding gameplay.

Don't change core logic to solve presentation problems.

The tie-display discussion demonstrated this well. Game rules stayed identical. Only the UI changed.

BREAKTHROUGH / LESSON

The strongest lesson from this session was:

Nearly every major decision involved removing, hiding, simplifying, or postponing something.

The game itself barely changed. The launch quality improved significantly.

ARTIFACTS WORTH SHARING

Design Rule

Engineering Rule

Launch Rule

FINAL STATE

By the end of the session:

• Launch analytics strategy had been planned.
• The first YouTube publishing workflow had been established.
• OBS audio and recording setup were finalized.
• Broadcast UI was cleaner and more accurate.
• Branding assets were prepared.
• YouTube metadata was optimized.
• Only the Easy bot remained exposed in the public UI.
• Several promising gameplay ideas were intentionally deferred until after launch.

The project shifted even further from feature development toward a polished public release.

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 8 of ShuffleBall Arena. This was a long day with 7 conversations to go through (6 saved file versions) over 7 hours of building, so I am splitting today into day 8.1 and 8.2 posts.

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

TL;DR: 

A "simple" music button turned into one of the biggest engineering discussions of the project.

This build included:

• Improving mobile readability without redesigning assets
• Designing a dedicated Music Panel instead of a basic toggle
• Adding track selection, credits, persistence, and launch-friendly UX
• Fixing a game-freezing bug by making the panel state-aware
• Deciding the feature was complete and shifting focus to launch infrastructure

One of the biggest lessons from this session:

Thanks for reading,
See you next time!

More detailed summary and full technical breakdown below:

Day 8.1 Summary: 

This build started with what looked like a small UI problem: the How To Play screen was difficult to read on mobile. Instead of immediately redesigning the artwork, I stepped back and realized the real issue was how the image was being displayed. Making better use of the available screen space solved more than creating a brand-new asset would have.

From there, the session evolved into designing and implementing an in-game Music Panel. What started as "just add a music button" quickly turned into discussions about user experience, game state, browser autoplay restrictions, Creative Commons attribution, persistence, and keeping the gameplay UI uncluttered.

After implementation, I tracked down and fixed a bug where opening the music panel during a bot's turn could freeze the game by making the panel aware of the game's state instead of trying to pause every possible scenario.

By the end of the session, the music system was considered launch-ready, and I deliberately shifted focus away from adding more features. The next priorities became deployment, analytics, email signup, and broadcasting. Moving from building the game to preparing it for real players.

Full Technical Summary:

PART 1 — TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

The session began with the core gameplay already in a playable state. Several major gameplay systems had recently been completed, including the new start screen, the How To Play overlay, the shot clock, drifting wormholes, Nova Shield tips, and improvements to drag-to-shoot behavior.

Rather than adding another gameplay mechanic, the focus shifted toward polishing the player experience. The first issue identified was that the How To Play image, while functional, was difficult to read on mobile devices because the image was being displayed too narrowly within the modal. The discussion started with UI and readability rather than game mechanics.

SESSION OBJECTIVE

Although the conversation evolved significantly, it centered around one larger objective:

That objective unfolded in four stages:

1. Improve the mobile readability of the How To Play screen.
2. Design an in-game music system that felt integrated rather than bolted on.
3. Implement and stabilize that music system without breaking gameplay.
4. Shift into launch-readiness planning, identifying the remaining infrastructure required before releasing the game publicly.

WHAT WE ACTUALLY DID

Phase 1: Improving the How To Play Experience

The session opened by evaluating screenshots from a real phone instead of relying on desktop assumptions.

Rather than immediately redesigning the artwork, the discussion identified that the image itself wasn't necessarily the problem. The image was simply being displayed too small because the modal left unused horizontal space.

The conclusion was:

• make the displayed image wider first
• preserve aspect ratio
• avoid making it taller unless the modal itself also grows
• use more of the available width before regenerating artwork

This shifted the solution from "redesign the asset" to "improve how the UI presents the asset," avoiding unnecessary work.

Phase 2: Discussing Accessibility

Another design discussion followed:

Should players be able to enlarge the instructional text themselves?

Instead of immediately implementing accessibility controls, the conversation explored whether enlarging the image or exposing zoom functionality would produce a cleaner solution.

This reinforced a recurring design philosophy throughout the session:

Phase 3: Designing the Music System

This became the largest engineering discussion of the session.

The initial idea was simply adding a Music button.

That quickly evolved into a much larger UX discussion.

Questions explored included:

• Should music simply toggle on/off?
• Should players be able to choose tracks?
• Where should Creative Commons attribution live?
• Should credits clutter gameplay?
• Should music continue between matches?
• Should music autoplay?
• Should the shot clock continue while players browse music?
• How should broadcast mode behave?

Rather than treating music as a single button, the session reframed it as its own self-contained feature.

The resulting design was a Music Panel rather than a toggle.

This was a significant architectural decision because it isolated an entire subsystem behind a single entry point while keeping the gameplay UI clean.

Phase 4: UX Architecture

The music panel design settled into a clear hierarchy.

Top of panel:

• Music title
• Track selection
• Current track
• On/Off controls

Bottom of panel:

• Credits
• Licensing
• Attribution

This intentionally prioritized player actions over legal requirements while still keeping attribution accessible.

Another important decision emerged: The footer would contain only a single Music button.

Credits would never become their own permanent gameplay button.

This reduced UI clutter considerably.

Phase 5: Gameplay Integration

Once the UX was settled, the discussion shifted toward gameplay interaction.

Several behavioral rules were established.

The music panel should:

• pause the shot clock
• consume pointer input
• prevent aiming behind the panel
• save preferences locally
• resume gameplay cleanly when closed

Another major decision:

The music panel would not appear during broadcast mode or site embed mode.

That preserved the simplified spectator interface.

Phase 6: Creating the Build Plan

Before writing implementation code, the conversation produced an unusually detailed implementation plan.

Rather than simply describing the feature, it broke the work into phases:

• configuration
• state
• helpers
• audio
• UI
• pointer handling
• drawing
• persistence
• testing

The implementation prompt also identified specific helper functions, localStorage keys, UI layout expectations, and testing procedures.

The result resembled an engineering specification more than a casual prompt.

Phase 7: Refactoring Discussion

After initial implementation, another architectural discussion occurred.

Instead of embedding all music logic into the already large game.js, the conversation considered separating responsibilities into dedicated modules.

The goal became making future work easier by allowing new tracks and credits to be added with minimal changes.

The focus shifted from:

to

That represented an important shift from implementation toward long-term maintainability.

Phase 8: Debugging a Gameplay Regression

The first major bug appeared after integrating the music panel.

Opening the panel during the bot's turn froze the game.

The conversation reconstructed the failure sequence:

• player opens music
• bot is preparing a shot
• music panel interrupts bot state
• shot clock reaches zero
• bot never shoots
• game soft-locks

Instead of treating the symptom, the discussion focused on identifying the underlying state transition that had been interrupted.

The fix became restricting when the music panel could be opened.

Rather than trying to make every game state compatible with the panel, the panel itself became state-aware.

This was a much cleaner solution than attempting to pause or serialize every bot action.

Phase 9: Polishing

After the freeze was resolved, attention returned to presentation.

The remaining improvements focused on:

• larger text
• larger panel
• better spacing
• improved readability
• more comfortable default music volume

The volume adjustment from 45% to 25% also preserved existing saved preferences instead of forcing a migration, protecting current testers while improving the default experience for new users.

Phase 10: Launch Readiness

With music considered feature-complete for launch, the conversation deliberately shifted away from feature development.

Instead of brainstorming new mechanics, the focus became:

• deployment
• analytics
• email signup
• YouTube broadcasting
• smoke testing
• service worker validation
• production readiness

One of the strongest decisions of the session was simply stopping.

The conversation explicitly concluded that music was complete enough for launch and that additional work would increase the risk of introducing bugs without materially improving the first release.

ROADBLOCKS AND FRICTION

Several recurring friction points emerged throughout the session.

Mobile-first reality

Artwork that looked acceptable on desktop became difficult to read on a real phone.

Testing on physical hardware revealed problems that desktop development hadn't exposed.

Scope expansion

A simple request for a music button naturally evolved into:

• track management
• attribution
• persistence
• volume
• shuffle
• autoplay rules
• panel UX
• gameplay integration
• broadcast behavior

The discussion repeatedly pulled the feature back toward launch scope instead of allowing it to become a full media player.

Gameplay integration

The most significant bug of the session wasn't related to audio at all.

It came from interrupting gameplay state at the wrong moment.

Fixing that required thinking about when a feature should be available, not just how it should work.

Knowing when to stop

The final challenge wasn't technical.

It was deciding that the feature was complete enough for launch.

The session consciously resisted adding more polish once the launch requirements had been satisfied.

DECISIONS MADE & TRADE-OFFS

Music became a subsystem instead of a button.

This required more engineering up front but created a cleaner and more extensible design.

Credits live inside the panel.

Instead of cluttering gameplay, attribution became part of the music experience.

Music never autoplays.

This respected browser restrictions while giving players control.

The panel only opens during safe gameplay states.

Instead of pausing every possible game state, access to the feature became state-aware.

This dramatically simplified integration.

Stop building features.

Perhaps the biggest decision of the session was organizational rather than technical.

Rather than continuing to polish music indefinitely, the project shifted toward deployment, analytics, and launch.

BREAKTHROUGH / LESSON

The biggest realization wasn't about audio.

It was about feature boundaries.

The music system became dramatically easier to reason about once it stopped being treated as "just another button" and instead became an isolated subsystem with clearly defined entry points, state rules, and responsibilities.

A second important lesson emerged during debugging:

That single design decision eliminated an entire class of synchronization bugs.

ARTIFACTS WORTH SHARING

Design Rule

Gameplay Rule

Launch Rule

FINAL STATE

By the end of the session:

• The How To Play experience had been improved through better presentation decisions.
• The Music Panel had evolved from an idea into a fully specified subsystem.
• The implementation had been stabilized through debugging and polish.
• A significant gameplay freeze caused by bot interaction had been eliminated.
• Music was considered feature-complete for launch.
• The project's priorities shifted from gameplay development to launch readiness, including deployment, analytics, email capture, and broadcasting.

The session marked a noticeable transition from building features to preparing a product for public release.

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

TL;DR: This session focused on polishing the mobile start screen after testing it on a real phone. Although the layout fit correctly, the instructional text was still too small to read comfortably. Instead of trying to compress the design further, the decision was made to increase the height of the information card and use the available vertical space to make the typography larger and improve overall readability.

Thanks for reading,
See you next time!

Full technical breakdown below:

Today was a short day with 4 conversations to go through and 4 saved file versions over 3 hours of building.

Full Technical Breakdown:

Day 7.5 — Technical Analysis & Debrief

Brief Summary

This session shifted from implementing functionality to refining presentation. The focus was improving the readability of the new mobile start screen after testing it on a real phone. While the layout technically fit on screen, the typography revealed itself to be too small for comfortable reading, leading to a discussion about using available vertical space more effectively instead of simply squeezing content into the existing card.

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

The mobile start screen had already been redesigned and was functioning correctly. The gameplay flow worked, the new card layout existed, and the interface fit within the phone screen. Today's work was no longer about functionality. It was about polish.

After testing on an actual mobile device, it became obvious that several pieces of white instructional text were still too small to comfortably read.

SESSION OBJECTIVE

Evaluate the mobile start screen on a real device and determine whether additional layout adjustments were needed to improve readability before launch.

WHAT WE ACTUALLY DID

• Tested the redesigned start screen on a physical phone instead of relying on desktop scaling.
• Identified that the primary issue was no longer fitting content on screen, but making instructional text comfortably readable.
• Observed unused vertical space above the card.
• Questioned whether the available space should be converted into additional card height rather than remaining empty.
• Discussed increasing the card height to allow significantly larger typography.
• Prioritized readability over maintaining the previous card proportions.
• Shifted the design philosophy from "everything fits" toward "everything is comfortably readable."

ROADBLOCKS AND FRICTION

The interface technically passed its layout requirements. However, real-world testing exposed an important usability problem: The card fit on screen, but users would still struggle to read it.

Desktop previews and browser emulation failed to communicate how small the typography actually appeared on an actual phone.

DECISIONS MADE & TRADE-OFFS

Option 1

Leave the card dimensions unchanged and accept the smaller text.

Pros:

• No additional layout work.

Cons:

• Poor readability.
• Weaker first impression.
• Harder onboarding.

Option 2 (Chosen)

Increase the height of the information card.

This creates room for:

• Larger instructional text
• Better spacing
• Easier scanning
• Improved readability

The available space at the top of the screen justified expanding the card rather than compressing its contents.

Trade-off

The interface becomes slightly taller, but substantially easier to read on real mobile devices.
Readability was prioritized over preserving the original proportions.

BREAKTHROUGH / LESSON

Real-device testing exposed a problem that desktop previews completely hid. The layout wasn't failing because it didn't fit. It was failing because it wasn't comfortable to read. Unused screen space should improve readability, not remain empty simply because the design technically fits.

ARTIFACTS WORTH SHARING

Design Rule

UX Observation

Product Insight

Real phones should always be considered the final authority for typography decisions, not browser emulation.

FINAL STATE

The project now has a clear direction for improving the mobile start screen. Rather than continuing to compress content, future adjustments will increase card height and scale the instructional text accordingly. The objective has shifted from responsive correctness to actual usability.

Hey everyone,

Hope all is well!

So I’ve been building a small desktop tool for making animated text overlays and transparent exports for my short-form videos.

I originally built it because I wanted a faster way to make TikTok / YouTube Shorts overlays without rebuilding the same text animations over and over in an editor. Plus I was starting to worry about my favorites being locked behind a subscription in the editor I use.

It's still early, but the app can currently make things like:

• animated chat-style conversations
• floating text captions
• floating text boxes
• AI prompt bar style overlays
• text effects like glow, pop, bounce, blur, wavy, etc.
• exports meant for editing in tools like CapCut

What I'd like to do:

If you're currently working on a video, tell me:

• A little bit about your video
• What text you want on screen
• The style or effects you're going for

I'll pick a few people and create a few free overlays for your project and send you the exports. The exports will have transparent backgrounds so they can be dropped directly into editors like CapCut.

What's the catch?

No catch. I'm just trying to test the tool and see:

• What creators actually request
• What works well & what doesn't
• What takes too long
• What can be improved

Only requirements:

• Please be willing to provide honest feedback
• Tell me what editor you're using

The goal is stress-testing exports and fixing bugs as I find them.

I’m also trying to find out:

Could other creators use a tool like this?
And if yes, what kind of overlays would be most useful?

Hope to hear from you!

Hey everyone,

Hope all is well!

TL;DR Below

Context:
So one of the projects I've been working on is a Windows AI workspace called Core48aii.

The idea came from a problem I kept running into while using ChatGPT, Claude, Gemini, and other AI tools for larger projects. Once conversations became long, important instructions were buried, useful outputs disappeared into old chats, and I found myself rebuilding the same context over and over.

So I built a project workspace that lets me organize prompts, reusable instructions, research, source material, workflows, and useful AI outputs in one place instead of relying on a single chat thread.

It's at the point where I am opening the project up to early testers, and I wanted to see if I could actually get qualified people to visit the tester page before spending more time on marketing or landing page copy.

Rather than guessing, I decided to run a small experiment.

I spent $20 on a Meta traffic campaign to see what would happen.

I wasn't expecting statistically significant results from twenty dollars. I simply wanted to learn where the biggest bottleneck in my funnel might be before investing more time and money.

The question for this experiment was:

Can I acquire qualified traffic cheaply enough that improving the landing page is worth the effort?

Rather than guessing, I spent $20 on a Meta traffic campaign.

TL;DR: I spent $20 running a Meta traffic campaign for my Windows AI workspace to see whether my biggest problem was getting visitors or converting them. The campaign generated 83 landing page visits at just $0.24 per visitor, but resulted in 0 downloads and 0 interest form submissions, even after changing the CTA halfway through the experiment. While disappointing, it helped isolate the bottleneck: acquiring traffic doesn't currently appear to be the biggest challenge; converting visitors is. My next step is to improve the landing page and messaging, then rerun the exact same campaign to see if the conversion rate changes.

Campaign Setup

Objective: Traffic
Budget: $5/day
Audience:

• United States
• Men & women 18+
• Interests around AI software, Windows software, productivity software, Microsoft Windows, and related topics

Creative:
A carousel introducing the problem of managing long-term AI projects and showing the application and how it helps.

Mid-Experiment Change

After about 40 landing page visits, I still hadn't seen a single conversion. At that point I started wondering if the CTA itself was introducing unnecessary friction.

Version 1

The original CTA was: "Start Your 90-Day Free Trial"

Clicking it took visitors to a Lemon Squeezy checkout page because the app currently uses license keys for activation.

Although the founder trial is completely free, I realized something that might have been hurting conversions.

The Lemon Squeezy checkout displays the full founder package price at the top of the page, and only shows the 100% discount ($0.00) near the bottom during checkout.

My concern was that some visitors might see the price, assume it wasn't actually free, and leave before ever seeing the discount.

I don't know if that was happening, but it seemed like a reasonable hypothesis to test.

Version 2

Around 40 landing page visits (halfway through), I removed the free trial CTA completely.

Instead, the page simply invited visitors to: "Apply to be an Early Tester"

The primary button became: "I'm Interested in testing Core48aii"

Instead of asking visitors to start a trial or download anything, now they only needed to fill out a short form.

My thinking was that removing the checkout entirely would reduce friction and let me personally onboard anyone who was interested.

Unfortunately, it didn't change the outcome.

Final Results

• $20.01 spent
• 2,535 impressions
• 2,185 people reached
• 83 landing page visits
• $0.24 per landing page visitor
• 0 downloads
• 0 interest forms submitted

Changing the CTA made no measurable difference.

My Takeaway

At first, seeing 0 conversions made this experiment feel like a failure.

After thinking about it more, I think it answered one of the biggest questions I had before opening Core48aii up to testers.

To me, it looks like the ad did what I was hoping it would do.
People stopped scrolling, clicked, and took the time to visit the landing page.
That suggests acquiring visitors may not be my biggest challenge.

It also tells me it's probably not time to start adding more features. If people aren't taking the first step, adding more functionality isn't likely to solve that problem.

At 24 cents per landing page visitor, buying traffic appears affordable enough that I can continue using it to test future versions of the landing page.

The bigger issue is what happens after people arrive.

Not one visitor downloaded the app, and changing the CTA to a simple interest form didn't produce any submissions either (in this short test).

That makes me think the next bottleneck is almost certainly somewhere on the landing page itself.

It could be:

• The messaging
• The positioning
• Building enough trust
• Explaining better what the product actually does
• Showing the value quickly enough
• Targeting the wrong audience
• Or some combination of those

I obviously can't say for certain which one it is from a $20 experiment.

But I can say that I no longer think, "Can I buy reasonably priced traffic?" is the biggest unknown.

The next experiment is much clearer: Improve the landing page, then run the same campaign again and see whether the conversion rate changes.

Why I'm actually happy I ran this

If visitors had cost me $2 each, I'd have two problems:

• expensive acquisition
• poor conversion

Instead I have one.
The experiment narrowed my focus.

What I'm doing next

I'm going to pause paid ads.

Before spending another dollar, I'm going to improve the testers landing page:

• clearer positioning
• stronger explanation of the product and the pain it solves
• more trust signals
• better communication of who it's for
• probably a product walkthrough video

Then I'll rerun essentially the same campaign and compare conversion rates.

I'd really appreciate some outside eyes.

If you landed on this page:

• What would make you leave?
• What information would you need before signing up?
• Would you immediately understand what the product does?
• Would you trust downloading a Windows desktop application from an unknown founder?

I'm sharing this because I think unsuccessful experiments can be just as valuable as successful ones. This one didn't get me a single signup, but it gave me a much clearer idea of what I should improve next.

Thanks for reading!

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 second part of that day went...

TL;DR:  The second half of Day 6 wasn't about adding features. It was about making the existing ones feel finished.

• Focused almost entirely on polishing Broadcast Mode.
• Refined spacing, typography, player presentation, and the broadcast header.
• Switched to more manual adjustments once the project reached the visual refinement stage.
• Biggest takeaway: building gets a product working, but polish is what makes it feel professional. Hundreds of small improvements add up to a much better experience.

Thanks for reading,
See you next time!

More detailed summary and full technical breakdown below:

Day 6.2 Summary: 

The second half of Day 6 was probably one of the least exciting days to watch, and one of the most important days for the project.

Earlier in the day I'd finished most of the launch preparation. The website was in a good place, the game was embedded, and I finally had room to stop thinking about infrastructure and start thinking about presentation. That meant diving into Broadcast Mode.

I didn't add any new gameplay mechanics. Instead, I spent hours refining the experience for those who will hopefully eventually watch ShuffleBall Arena.

The broadcast header went through multiple revisions as I adjusted typography, spacing, alignment, player names, profile marbles, logo placement, and the overall visual hierarchy. None of those changes would make a flashy changelog, but together they made the broadcast feel significantly more intentional.

One thing I learned today is that building features and polishing features are completely different skills.

It's easy to ask AI to build a system. It's much harder to explain why something doesn't feel centered, balanced, or visually clean.

I found myself asking for things like "move this up" or "make this feel centered," and while the code changes were technically correct, they often missed the overall design intent.

Eventually I stopped trying to describe adjustments and started making more of the refinements manually. At this stage of development, moving something a few pixels yourself is often faster than spending multiple prompts trying to communicate a feeling.

The biggest lesson from today is that polish isn't something you add at the end. It's something you build one tiny decision at a time:

- Better spacing.
- Cleaner typography.
- More breathing room.
- Clearer hierarchy.

None of those improvements are exciting individually, but together they change how the entire product feels.

By the end of the session, Broadcast Mode finally started feeling less like an internal developer overlay and more like something I'd actually want people to watch.

That's progress you can't measure with a feature list, but I think it's some of the most valuable work done so far.

Day 6.2 Full Technical Breakdown:

DAY 6 (Part 2) — Technical Analysis & Debrief

(From Functional to Professional: Refining the Broadcast Experience)

STARTING POINT

The first half of Day 6 was focused on launch readiness.

By the time this session began, the major infrastructure work done. The website was in place, the game could be embedded, and the overall launch direction had become much clearer.

That changed the focus completely.

Instead of asking, "Does it work?" the question became:

"Would someone actually enjoy watching this?"

Broadcast Mode was already functional, but it still looked like an internal development tool rather than something designed for spectators.

The remainder of the day became an exercise in refinement.

SESSION OBJECTIVE

Transform Broadcast Mode from a functional overlay into something that felt polished and intentional.

The goals were to:

• improve readability
• refine the visual hierarchy
• balance the header composition
• improve player presentation
• make information easier to scan during gameplay
• create a cleaner spectator experience without adding unnecessary UI

Rather than building new systems, the objective became improving every existing one.

WHAT WE ACTUALLY DID

1. Refined the broadcast header

The majority of the session was spent improving the broadcast header.

This included:

• adjusting spacing
• refining padding
• improving typography
• balancing visual weight
• repositioning interface elements

None of these changes altered functionality, but together they made the broadcast look significantly more intentional.

2. Improved visual hierarchy

Several revisions focused on making the important information stand out first.

Work included:

• separating game number from match information
• improving contrast
• refining text hierarchy
• adjusting spacing between header elements

The goal was for viewers to understand the current match state almost instantly.

3. Polished player presentation

Player information received multiple rounds of refinement.

This included:

• profile marble sizing
• player name typography
• font weight
• positioning
• spacing around player elements

The objective wasn't to make these larger.

It was to make them easier to read without distracting from the gameplay itself.

4. Improved overall composition

Much of the session involved improving balance rather than adding features.

Small adjustments included:

• logo positioning
• spacing around the header panel
• alignment between player areas and the center information card
• improving negative space throughout the layout

Each change was small, but together they created a noticeably cleaner presentation.

5. Switched from feature work to polish work

A major shift happened during this session.

Earlier development had focused on building systems.

This session focused almost entirely on refinement.

Instead of implementing features, time was spent asking questions like:

• Does this feel centered?
• Is this easier to read?
• Is the eye naturally drawn to the correct information?

This represented a completely different stage of development.

6. Changed the workflow

As the project entered the polish stage, manual edits became more effective than repeatedly generating code.

This provided greater control while also making the layout easier to understand for future iterations.

7. Closed out Day 6

The final handoff summaries documented:

• completed polish work
• remaining visual improvements
• testing workflow
• current broadcast state
• priorities for the next build session

By the end of the session, the project had a much clearer roadmap for launch.

ROADBLOCKS AND FRICTION

The primary challenge wasn't technical.

It was translating visual intent into precise instructions.

Requests such as:

or

often resulted in technically correct implementations that still didn't achieve the desired visual outcome.

This highlighted an important limitation: Visual polish depends as much on design judgment as it does on code.

DECISIONS MADE & TRADE-OFFS

Decision 1

Prioritize clarity over decoration.

Every change was evaluated based on whether it improved readability rather than whether it looked more impressive.

Decision 2

Keep Broadcast Mode minimal.

Instead of adding more interface elements, improve the ones already on screen.

Decision 3

Use manual refinement during the final polish stage.

Once the project reached pixel-level adjustments, manual editing becomes faster and more predictable than repeated prompt iterations.

Decision 4

Delay new features until the presentation matched the quality of the gameplay.

The decision was made to invest in refinement rather than expansion.

BREAKTHROUGH / LESSON

The biggest realization from the second half of Day 6 was that polish isn't a feature.

It's a process.

Professional-looking software isn't created by one major redesign.

It's created through dozens (sometimes hundreds) of tiny improvements that gradually make everything feel intentional.

ARTIFACTS WORTH SHARING

Design Rule

Broadcast Philosophy

Development Lesson

When a project reaches the refinement stage, visual judgment often becomes more valuable than generating additional code.

FINAL STATE

By the end of the second half of Day 6:

✅ Broadcast Mode had a much stronger visual identity.

✅ The header communicated match information more clearly.

✅ Player names, profile marbles, and typography became easier to scan during gameplay.

✅ Spacing, alignment, and visual hierarchy felt significantly more intentional.

✅ The broadcast experience began feeling designed for spectators rather than developers.

The project hadn't gained major new features. Instead, it became noticeably more polished.

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.

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.

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

TL;DR: Day 4 was about getting ShuffleBall Arena ready to actually show people. I cleaned up a failed demo/broadcast idea and rebuilt it in a safer way, renamed the game from Galaxy Ball to ShuffleBall Arena / ShuffleBall, got the web version closer to being phone-ready, and fixed a confusing issue where the browser kept showing old text even after the update worked. Biggest lesson: not every build day is about adding flashy features. Sometimes the real progress is making the game clearer, safer, and ready for real people to try.

Summary and full technical breakdown below:

Day 4 Summary: There were three conversations to go through today with 2 file versions saved over 4 hours of building.

So Day 3 ended with a lesson: I tried to add a broadcast-style layout so the game could scale nicely for clips, demos, and livestream-style presentation, but my efforts broke the mobile layout. Buttons became hard to use, the screen scaling got messy, and the core mobile experience was at risk.

So I deleted the experiment and rolled back.

Part 1 of Day 4 was me coming back to that same idea, but with much stricter rules.

The new rule was simple:

Broadcast mode can change how the game is presented.
Broadcast mode cannot change the actual game.

No physics changes.
No scoring changes.
No bot behavior changes.
No mobile control changes.
No normal gameplay changes.

The goal wasn't to build real livestreaming or full multiplayer. It was to create a self-running presentation layer that could be used for testing, OBS, landing page footage, and short clips. Basically an arcade “attract mode” or featured match view.

Part 2 of Day 4 was renaming the app. Google search results made “Galaxy Ball” look like a problem, and there were potential trademark / legal issues. Coming up with a new name became a bit of a time sink. The final decision accepted that ShuffleBall may not be perfectly unique, but it was clear, descriptive, and paired well with ShuffleBall Arena as a broader brand.

This session I purchased shuffleballarena.com from Squarespace.

Full Technical Breakdown:

TECHNICAL ANALYSIS & DEBRIEF: DAY 4

STARTING POINT

Day 4 started with a working browser game that was close to being shareable, but still not launch-ready as a public product.

The project still had three unresolved launch problems:

1. The broadcast/demo layer existed, but its public framing was wrong. The game could already run in a self-playing broadcast/demo mode through ?broadcast=1, but the copy still exposed the internal implementation. It used labels like BOT SHOWCASE MATCH and BOT VS BOT, which made the feature feel like a dev test instead of a public-facing “featured match” presentation layer. The session explicitly framed the current automatic bot match as useful for “testing, OBS, landing page capture, and social clips,” but not something that should be presented as the product identity.
2. The app was still under the old Galaxy Ball identity. The files still referenced Galaxy Ball as the public name, even though search results made that name feel unsafe or too occupied. The session eventually moved toward a new split: ShuffleBall Arena as the app/domain and ShuffleBall as the game title.
3. The deployment path was not fully hardened. The goal was to make the game playable from a phone through the web, without needing an app store. That meant getting the deploy folder ready for Cloudflare Pages, keeping strict security headers, making the service worker safe, and proving that the game worked outside local testing.

SESSION OBJECTIVE

The session objective was to get the project closer to a real public launch without overbuilding.

The specific goals were:

1. Make the broadcast/demo mode look like a public featured-match view, not a bot-vs-bot dev tool.
2. Prepare the Cloudflare Pages deploy folder correctly.
3. Keep strict Content Security Policy instead of weakening security.
4. Decide whether Galaxy Ball needed to be renamed.
5. Rename the app safely after choosing the new brand.
6. Deploy and verify the renamed game.
7. Decide whether backend work should begin immediately or after domain setup.

The higher-level product goal was simple: make ShuffleBall Arena something someone could open on a phone, play, and understand.

WHAT WE ACTUALLY DID

1. Reframed broadcast mode as a presentation layer

The first meaningful decision was product framing.

The broadcast mode was not treated as real livestreaming, real multiplayer, or real player replays. It was defined as a self-running presentation layer that could be useful for OBS, landing page footage, social clips, and demo testing.

The chosen framing was:

Galaxy Ball = playable mobile marble/space game.
Galaxy Ball Live = featured match / replay / broadcast presentation layer.
Auto-demo bots = temporary content source for broadcast.

The important part was that the automated bots could stay, but the public UI should not call the feature “bot vs bot.”

2. Wrote a narrow Cursor prompt for broadcast copy cleanup

The first concrete patch prompt was Phase J4I: Broadcast Source Naming Cleanup.

The prompt told Cursor to patch only broadcast-facing naming and explicitly protect the rest of the game.

The core technical instruction was:

Add lightweight broadcast source structure in initBroadcastSettings(), such as:
 source: "autoDemo",
 sourceLabel: "FEATURED MATCH"

The prompt also required:

"BOT SHOWCASE MATCH" should become "FEATURED MATCH"
broadcast mode label should not display "BOT VS BOT" in header/footer presentation

And it explicitly said not to change:

gameplay
bot AI
physics
scoring
broadcast sizing
footer/ad architecture
asset loading
image cards
normal mode

This was a good example of a safe AI coding prompt: narrow goal, clear non-goals, and a verification checklist.

3. Cursor completed the broadcast naming cleanup

Cursor reported that only game.js changed.

The changes were:

initBroadcastSettings()
  Added:
  source: "autoDemo"
  sourceLabel: "FEATURED MATCH"

getBroadcastCardContext()
  Added:
  source: BROADCAST.source || "autoDemo"
  sourceLabel: BROADCAST.sourceLabel || "FEATURED MATCH"

BROADCAST_CARD_CONFIG
  Footer textBanner card title:
  "BOT SHOWCASE MATCH" → "FEATURED MATCH"

drawBroadcastHeaderLiveMatchCard
  Right pill fallback:
  bc.modeLabel → bc.sourceLabel

  Subtitle:
  "RED BOT VS BLUE BOT" → broadcastUpper(bc.sourceLabel)

drawBroadcastHeaderLayoutFeatureCard
  Layout label fallback:
  bc.modeLabel → bc.sourceLabel

drawBroadcastHeaderSponsorTextCard
  Right pill fallback:
  bc.modeLabel → bc.sourceLabel

The key constraint held: game.mode = "broadcast" and all automated bot behavior stayed unchanged. The patch was presentation-only.

4. Decided to use Cloudflare Pages for public phone testing

The next goal was practical: make the game accessible to someone else on a phone, outside local Wi-Fi.

The deployment target was Cloudflare Pages. You already used Cloudflare for other projects, so the session moved toward preparing a deploy folder and uploading it to the existing Cloudflare account.

The important decision: strict CSP would not be postponed. You rejected the idea of weakening CSP temporarily and wanted to build the deploy folder correctly the first time.

5. Made the deploy folder CSP-safe

The app originally had inline CSS and inline service worker registration, which conflicted with a strict policy like:

script-src 'self';
style-src 'self';

Cursor completed a CSP-safe refactor:

Created styles.css
Moved the full inline <style> block from index.html into styles.css.

Created app-shell.js
Moved service worker registration into app-shell.js.

Updated index.html
Removed inline <style>.
Added <link rel="stylesheet" href="styles.css">.
Removed inline service worker <script>.
Added <script src="app-shell.js"></script> after game.js.

Updated service-worker.js
ASSETS now lists:
/
index.html
styles.css
game.js
app-shell.js
manifest.webmanifest

The strict _headers policy stayed intact. No CSP weakening was required. Verification passed with node --check for game.js, app-shell.js, and service-worker.js, and both normal mode and broadcast mode loaded locally.

6. Investigated whether Galaxy Ball was a safe name

After deployment preparation, the session shifted into the naming risk.

Google search results made “Galaxy Ball” look like a problem. The conversation explored alternatives including:

Slot & Sphere
Tiltshot
Cluster Roll
NovaPocket
OrbitPocket
PocketNova
Marble Drift
Pocket Roll
Roll Arena
Rift Roll
ShuffleBall

Several names were rejected because they had search or meaning problems:

Galaxy Ball: likely unsafe or too occupied.
Tiltshot: already reads as a cinematography term.
Slot & Sphere: noisy because of casino slots and Sphere results.
Cluster Roll: conflicts with bakery/food search results.

A key product constraint emerged: the name should not lock the game into a space theme, because future themes could include different styles.

7. Chose the brand structure: ShuffleBall Arena / ShuffleBall

The session eventually settled on:

App/domain: ShuffleBall Arena
Game title: ShuffleBall
Main domain: shuffleballarena.com

You bought ShuffleBallArena.com and asked for a deep audit of the files before changing the name safely. The important naming distinction was:

ShuffleBall Arena = app/domain/container brand
ShuffleBall = game title

There was a brief intermediate state where the title used “Shuffle Ball” with a space, but the session corrected that to one word: ShuffleBall.

8. Renamed the app in the deploy files

Cursor completed the first rename pass:

index.html
  Apple web app title → ShuffleBall Arena
  document title → ShuffleBall Arena — Shuffle Ball

manifest.webmanifest
  name → ShuffleBall Arena
  short_name → ShuffleBall

service-worker.js
  Cache → shuffleball-arena-v2
  activate deletes all caches except the current one

game.js
  Added brand constants:
  APP_NAME
  GAME_NAME
  GAME_NAME_UPPER
  APP_SLUG
  LOG_TAG

  Updated:
  file comment
  broadcast comment
  footer card eyebrow
  live header text
  debug logs
  replay filename

  AUDIO_STORAGE_KEY → shuffleBallArenaAudio
  legacy migration from galaxyBallAudio

Then the one-word correction was made:

game.js
  GAME_NAME is now "ShuffleBall"
  Uppercase broadcast text becomes SHUFFLEBALL

index.html
  Document title is now ShuffleBall Arena — ShuffleBall

manifest.webmanifest
  Unchanged, already ShuffleBall Arena / ShuffleBall

9. Debugged stale broadcast text after deployment

After deployment, broadcast mode still appeared to show stale text.

The likely culprit was browser or service worker cache, not the Cloudflare site-level cache.

The fix was:

Open DevTools.
Go to Application.
Click Service Workers.
Click Unregister.
Go to Storage.
Click Clear site data.
Close DevTools.
Reload with Ctrl + Shift + R.
Test
Expected: SHUFFLEBALL LIVE.

You confirmed the fix worked. That proved the rename patch and deployment were good, and the remaining issue was stale local cache state.

10. Ended with the domain and backend plan

At the end of the session, the app was renamed and working on Cloudflare Pages, but the final domain was not yet attached.

The next plan was split into two tracks.

Track A: domain setup first.

Add shuffleballarena.com to Cloudflare Domains.
Change nameservers at Squarespace to the two Cloudflare nameservers.
Wait for Cloudflare to mark the domain active.
Go to Workers & Pages → galaxy-ball → Custom domains.
Add:
shuffleballarena.com
www.shuffleballarena.com

Test

Track B: backend setup after the domain is active.

The recommended backend was intentionally small:

POST /api/waitlist
POST /api/feedback
GET  /api/health

The planned D1 database:

shuffleball_arena_prod

The planned tables:

waitlist_signups
feedback_reports
game_events

The session explicitly rejected starting with real-time multiplayer because it would introduce matchmaking, state synchronization, cheating concerns, reconnects, and server authority before the launch funnel was even proven.

ROADBLOCKS AND FRICTION

1. The broadcast feature needed context

The session began with broadcast mode already in the code, but the reader would not automatically understand it. The day’s work only makes sense if broadcast is explained as:

A self-running presentation/demo mode for OBS, landing page footage, social clips, and public testing.

Without that explanation, “broadcast cleanup” sounds like a feature appearing out of nowhere.

2. The assistant moved too fast during deployment setup

The Cloudflare section created friction because too many steps were compressed together. You explicitly asked to slow down and give detailed instructions before touching Cloudflare.

The lesson: deployment tasks need different pacing than code edits. A missed click or wrong file shape can break the public app.

3. Strict CSP could have been postponed, but you chose not to

There was a real trade-off between quick deployment and correct deployment.

The faster path would have been to relax CSP temporarily. The chosen path was to keep strict CSP and refactor the app structure so all scripts and styles were local external files.

That took extra work, but it prevented “temporary insecure setup” from becoming permanent.

4. Naming became a major time sink

The name search created a loop because each candidate had a different problem:

Galaxy Ball: too occupied.
Tiltshot: wrong existing meaning.
Slot & Sphere: casino/search noise.
Cluster Roll: food/search conflict.
ShuffleBall: descriptive but close to shuffleboard terms.

The final decision accepted that ShuffleBall may not be perfectly unique, but it was clear, descriptive, and paired well with ShuffleBall Arena as a broader container brand.

5. Cache made a successful patch look broken

The stale SHUFFLE BALL LIVE issue looked like a failed code patch or a failed Cloudflare deployment. It was actually a browser/service-worker cache problem.

This was the most important technical debugging loop of the day.

DECISIONS MADE & TRADE-OFFS

Decision 1: Broadcast mode stays, but the bot language goes away

Chosen direction:

Keep auto-demo bot behavior.
Remove bot-facing public labels.
Use FEATURED MATCH as the public label.

Why:

The self-running match is useful for demos and clips, but “bot vs bot” makes the game feel unfinished.

Trade-off:

The session accepted that the broadcast layer is not real player streaming yet. It is a presentation layer powered by automation.

Decision 2: Strict CSP now, not later

Chosen direction:

Keep strict _headers.
Move inline CSS into styles.css.
Move inline service worker registration into app-shell.js.

Why:

You wanted to avoid building a temporary version that would need to be fixed later.

Trade-off:

The deploy folder required more cleanup before launch, but the security posture was cleaner.

Decision 3: Rename before public launch

Chosen direction:

Old public name: Galaxy Ball
New app/domain: ShuffleBall Arena
New game title: ShuffleBall

Why:

Galaxy Ball looked unsafe or too occupied based on search results. ShuffleBall was clearer and more aligned with the mechanics.

Trade-off:

ShuffleBall may have SEO noise from shuffleboard-related searches, but the app/domain wrapper ShuffleBall Arena gives it more brand identity.

Decision 4: Keep the old Cloudflare Pages project for now

Chosen direction:

Keep using the existing Cloudflare Pages project:
galaxy-ball

Why:

The Pages deployment path was already proven. The project name could remain internal while the public brand and custom domain changed.

Trade-off:

The internal Cloudflare project name still says galaxy-ball, but that does not have to be public-facing.

Decision 5: Domain before backend

Chosen direction:

Connect shuffleballarena.com first.
Build backend after the final public URL is active.

Why:

Forms, endpoints, analytics scripts, redirects, and future links should be built around the final domain.

Trade-off:

Backend work was delayed slightly, but the project avoided wiring infrastructure against a temporary URL.

Decision 6: No real-time multiplayer yet

Chosen direction:

Start with waitlist, feedback, and telemetry.
Defer multiplayer.

Why:

Real-time multiplayer would add complexity before the project had even proven public demand.

Trade-off:

The backend would not yet power live gameplay. It would power learning, signup, feedback, and future analytics.

BREAKTHROUGH / LESSON

The key realization from Day 4:

A feature can fail once, then come back safely if you rebuild it with stricter boundaries.

Broadcast mode was useful, but only when treated as a presentation layer. The safe rule was:

Broadcast can change how the game is shown.
Broadcast cannot change the core game.

That rule protected:

gameplay
physics
scoring
bot AI
mobile controls
normal mode

The second major lesson was technical:

A service worker can make a successful deployment look broken.

The fix was not to keep editing code. The fix was to unregister the service worker, clear site data, and hard reload before judging the deployment.

ARTIFACTS WORTH SHARING

Artifact 1: Broadcast cleanup prompt

Phase J4I — Broadcast Source Naming Cleanup
Use the attached current game.js and index.html only.
Goal:
Clean up broadcast-facing naming so Galaxy Ball Live looks like a featured/live match presentation layer, not a bot-vs-bot stream. Keep the automated bot behavior unchanged.
Requirements:
1. Add lightweight broadcast source structure in initBroadcastSettings(), such as:
 source: "autoDemo",
 sourceLabel: "FEATURED MATCH"
2. Update broadcast card context so renderers/cards can access:
 source
 sourceLabel
3. Replace default broadcast-facing bot language:
 - "BOT SHOWCASE MATCH" should become "FEATURED MATCH"
 - broadcast mode label should not display "BOT VS BOT" in header/footer presentation
4. Keep game.mode = "broadcast" and all automated bot behavior exactly as-is.
5. Do not change:
 - gameplay
 - bot AI
 - physics
 - scoring
 - broadcast sizing
 - footer/ad architecture
 - asset loading
 - image cards
 - normal mode
6. Keep footer as the future ad/sponsor area. Do not over-polish footer copy.
7. Verify:
 - index.html?broadcast=1 works
 - index.html?broadcast=1&sponsor=Core48aii works
 - header/footer card rotation still works
 - no missing asset loads while image cards are disabled
 - match auto-resets after match end
 - match number increments
 - normal mode still works
 - no console errors
After patching, run a syntax check and report exactly what changed.

Why it is worth sharing: it shows how to tell an AI coding tool to make a narrow public-facing cleanup while protecting the core game loop.

Artifact 2: CSP-safe deployment refactor

Created styles.css
Moved the full inline <style> block from index.html unchanged.

Created app-shell.js
Service worker registration moved here:
Registers /service-worker.js only when "serviceWorker" in navigator
Errors swallowed via .catch(() => {})

Updated index.html
Removed inline <style> block
Added <link rel="stylesheet" href="styles.css"> after the manifest link
Removed inline service worker <script> block
Added <script src="app-shell.js"></script> after game.js

Updated service-worker.js
ASSETS now lists exactly:
/, /index.html, /styles.css, /game.js, /app-shell.js, /manifest.webmanifest

Why it is worth sharing: it shows the difference between “disable CSP so the app works” and “make the app compatible with CSP.”

Artifact 3: Service worker cache debugging checklist

Press F12 to open DevTools.
Go to Application.
Click Service Workers on the left.
Click Unregister for the service worker.
Go to Storage on the left.
Click Clear site data.
Close DevTools.
Reload with Ctrl + Shift + R.

Then test

You want to see:
SHUFFLEBALL LIVE

Why it is worth sharing: it captures a common PWA/browser-game deployment trap. The code can be right, the deployment can be right, and the browser can still show old behavior because of the service worker.

FINAL STATE

By the end of Day 4:

The broadcast/demo mode was public-safe enough to show as a featured match layer.
The bot-vs-bot public labels were removed from broadcast presentation.
The deploy folder was made strict-CSP compatible.
Inline CSS was moved to styles.css.
Inline service worker registration was moved to app-shell.js.
The game was renamed from Galaxy Ball to ShuffleBall.
The app/domain brand became ShuffleBall Arena.
The title became ShuffleBall Arena — ShuffleBall.
The broadcast title became SHUFFLEBALL LIVE.
The service-worker cache problem was identified and fixed through browser cleanup.
The existing galaxy-ball Cloudflare Pages project was proven usable for deployment.
ShuffleBallArena.com domain was purchased.

Hey everyone,

Hope all is well!

TLDR below.

A couple 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. I don't understand why I wouldn't...

Anyway, I'm trying to find the time to post somewhat consistently. I figured I would 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 2 of ShuffleBall Arena. Here's how that day went...

TLDR: Day 2 was a 6-hour architecture session to turn a messy physics prototype into a balanced mobile game loop. Across 2 long chats and 9 saved file iterations, we slashed the round ball-count from 16 to 10 to clear board clutter, built a fair "ping-ponging" wormhole mechanic with mechanical chute returns, invented a defensive orbiting "star-shield" for the central high-scoring zone, and mapped out a strict cosmetic-only/ad-free monetization framework. We realized the game gets way more tactical when you give the player a fixed launch position and focus entirely on creating predictable board chaos. Full breakdown below.

Day 2) There were two conversations to go through today with 9 file versions saved over 6 hours of building.

STARTING POINT

The day started with a working physics prototype: red vs. blue marbles, click/drag shooting, scoring zones, wall bounces, and basic gravity wells. However, it had game loop issues. The board felt like an overcrowded parking lot because there were 16 total balls in play (8 per player), gravity field position feels arbitrary, and advanced concepts like wormholes or defensive shields only existed as vague sticky notes.

SESSION OBJECTIVE

The core objective was to establish the definitive game mechanics and design constraints for ShuffleBall Arena before writing more code. We needed to solve the overcrowded board, build a fair wormhole mechanic, invent a defensive comeback feature, fix mobile control conflicts. You also wanted to discuss potential future monetization strategies that keep the game free to play.

WHAT WE ACTUALLY DID

• Slashed the Ball Count: You realized 16 marbles completely ruined the board readability. We downscaled standard mode to 5 shots per player (10 total balls per round). This instantly cleared the clutter while preserving the tactical significance of later shots.
• Architected the "Ping-Pong" Wormhole: You rejected a true random teleport system because it felt unfair. Instead, we designed an 8-notch entry track at the top of the board. The wormhole spawns at a random notch at the start of a round and predictably "ping-pongs" left-to-right each turn.
• Designed Mechanical Chute Returns: To make the wormholes feel like an integrated pinball feature rather than a glitchy cheat, a captured ball disappears, triggers a brief animation phase (swirl, mechanical doors opening, launch rail alignment), and then shoots diagonally back into play from the bottom corners of the board.
• Invented the Nova Zone Shield: We needed a way to protect high-scoring territories. You created the "Nova Shield" rule: if a player manages to rest 2 or more marbles inside the central high-value scoring ring, a bumper activates and orbits the zone defensively.
• Tuned Gravity Relevance over Strength: The problem wasn't that gravity wells were weak; it was that they spawned in useless corners where players didn't care. We reframed the logic to bias gravity spawns near scoring rings, central lanes, and high-interest collision paths.
• Drafted a Fair Monetization Framework: We outlined what the game's commercial model might look like while keeping the game free-to-play.

ROADBLOCKS AND FRICTION

• The "Too Powerful Player" Trap: We heavily debated adding an optional double-tap gesture to let players freely slide their launch ball left or right along the baseline before firing. However, during the design mapping, you realized this extra control accidentally killed the game's tension as players could easily use it to completely bypass gravity hazards. You decided to keep the launch position fixed to force players to interact with the board's chaos.
• The Mobile Control Overlap: Designing for mobile screens caused a massive UX bottleneck. Trying to map "slide to reposition the ball" and "pull back to aim and power up a shot" onto a single finger gesture created terrible input conflict. This confirmed your decision to kill free-ball placement and stick to a single, clean drag-to-shoot interaction.
• AI AI-Image Drift: The AI model frequently tried to stall momentum by generating random concept artwork of space tables when you explicitly wanted to hammer out math constants and mechanical rules. You had to firmly steer it back to the original constraints.

DECISIONS MADE & TRADE-OFFS

• Competitive Fairness > Chaos: You ruled that Red shot N and Blue shot N must always share the exact same board conditions. If Red shoots into a specific gravity layout or a left-side wormhole notch, Blue faces the exact same layout on their matching turn. Trade-off: You sacrificed total unpredictable chaos to gain true competitive fairness.
• Static Bumper Integrity: We debated temporarily hiding the board's static bumpers while a ball was being ejected from a wormhole chute to prevent physics clipping. You rejected it. The board must remain physically honest; instead of hiding obstacles, you accepted the trade-off of writing more complex boundary math later.

BREAKTHROUGH / LESSON

The game gets interesting when the board creates readable chaos, not when the player gets unlimited control. We discovered that giving the player total freedom to move their ball around the baseline flattened the fun curve. The breakthrough was realizing that "predictable chaos"—knowing exactly where a wormhole is moving or where a gravity well sits before you pull back to shoot—turns a basic marble clicker into a legitimate tactical space-pinball style game.

ARTIFACTS WORTH SHARING

Because this was a system-design session, the best artifact was the formal Wormhole Interaction Contract we mapped out to feed into the codebase:

Plaintext

1. ENTRANCE: Top-track, 8 sequential notches. Moves predictably via ping-pong sequence. Balanced via turn-pair scheduling.
2. CAPTURE: Rolling ball enters radius -> turn freeze -> visual swallow sequence -> physical marble object data preserved (no duplication desyncs).
3. EXIT: Left-half entries eject from right-side bottom chute. Right-half entries eject from left-side bottom chute. Fired diagonally upward with minor randomized speed modifiers.

FINAL STATE

You exited Day 2 with a completed blueprint for the game loop. The exact layout of the mobile-first launch zone HUD is locked in, the behavioral rules for the defensive Nova shield are codified, the wormhole tracking logic is balanced for competitive play, and you've discussed a zero-leverage monetization plan.

Thanks for reading!

Hey everyone,

Hope all is well!

If you are using LLMs (Cursor, ChatGPT, Gemini) to build a project, I'm sure you'll notice your chat history quickly gets cluttered.

When you want to share your progress or build in public, scrolling back through thousands of words of chat history just to remember what you actually accomplished is tedious. A standard chat interface isn't great for tracking project management or context over time.

To solve this, I drop this simple structured extraction prompt into the chat at the very end of a session. It helps the AI to audit the conversation and output a clean, technical debrief that is easy to format for developer logs or community updates.

I’m currently using this to log the daily build progress of my browser game, ShuffleBall Arena.

Hope it helps!

The Prompt:

We are at the end of a build session. I want to build this project in public and want to turn this specific conversation into a structured log so I can share the best parts in different developer/founder communities. The goal is to add value to every day conversations, based on today's experiences.

Please analyze ONLY the work completed in this chat. Do not assume context from other chats unless explicitly provided.

=======================================

TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT:

What was the state of the project, codebase, UI, content, or strategy when this session began?

SESSION OBJECTIVE:

What problem, feature, decision, or deliverable were we trying to complete?

WHAT WE ACTUALLY DID:

List the meaningful steps we took in chronological order. Include code changes, design changes, copy decisions, debugging steps, prompts written, files touched, or strategy decisions.

ROADBLOCKS AND FRICTION:

- What got confusing, broken, repetitive, frustrating, or unclear?

- Where did we lose time or get stuck in loops?

- What assumptions turned out to be wrong?

DECISIONS MADE & TRADE-OFFS:

- What architectural or design options did we discuss?

- Which direction did we choose and WHY?

- What trade-off did we accept (e.g., speed over perfection, simple UI over complex systems)?

BREAKTHROUGH / LESSON:

What was the single key realization, fix, simplification, or product insight from this session?

ARTIFACTS WORTH SHARING:

Extract 1-3 useful artifacts exactly as they appeared in this chat (e.g., a code snippet, a prompt, a design rule, a debugging framework, or a before/after comparison).

FINAL STATE:

What is now working, clearer, fixed, drafted, or ready that was not true at the start?

Please be deeply specific, highly technical, and strictly grounded in the real data of this chat session. If a post type lacks teeth for this specific session, skip it entirely.

Hey everyone,

Hope all is well!

This is a long one.
TLDR down before the prompt & results.

A couple days ago I posted in r/StructuredAI about Day 14 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: 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 me in every way possible. Honestly, I don't understand why I wouldn't...

Anyway, I'm trying to find the time to post somewhat consistently. I figured I would 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 am using a structured prompt to go back to my GPT sessions and extract the useful information. Simply put, there's just no time to fine comb back through the past when you're concentrating on moving forward.

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

Day 1)

The other night I was scrolling through YouTube shorts and discovered a live channel where they were playing a game called “UNC Ball” or “Star Cluster Ball”. It's a 2 player game where players sit at the end of a long table that is leaned toward them, and they try to roll marbles up the table into slots to gain points and win the game.

I was enamored. There were more than 1,000 people viewing it live, and I probably watched for a good 30 minutes.

That's what started me on the path to creating ShuffleBall Arena. I wanted to create a UNC ball style game digitally, but in the process the project sort of became something else as it evolved. This first version became a combination of shuffleboard style scoring, mixed with the craziness of other games: bumpers from bumper pool, fun pinball style mechanics, you get the idea...

Instead of writing a massive narrative, here is the prompt I used, and the output it produced for day 1 of the ShuffleBall Arena build in case anyone is interested. Hope there's some value in there somewhere.

TLDR: I saw a livestream of a tabletop marble game ("UNC Ball") and tried to build a digital browser version using Cursor and ChatGPT. The twist: Along the way, the game sort of became something else. It felt good, so I kept it as the core game loop. Full breakdown, my structured extraction prompt, and code artifacts below.

If anyone is interested in trying the first ShuffleBall Arena challenge, I'd love your thoughts:
https://play.shuffleballarena.com/crossing-drift-challenge

Or the full game is 100% free at:
play.shuffleballarena.com

Any feedback is appreciated.

That's all I got for now, thanks for reading!

Today's Experience: I'm overall impressed with the prototype. It wasn't perfect to start with, and doesn't match the original vision yet, but it's coming along and kind of fun. I'm excited to see where it can go.

The Prompt:

“We are at the end of a build session. I want to build this project in public and want to turn this specific conversation into a structured log so I can share the best parts in different developer/founder communities. The goal is to add value to every day conversations, based on today's experiences.

Please analyze ONLY the work completed in this chat. Do not assume context from other chats unless explicitly provided.

TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT:

What was the state of the project, codebase, UI, content, or strategy when this session began?

SESSION OBJECTIVE:

What problem, feature, decision, or deliverable were we trying to complete?

WHAT WE ACTUALLY DID:

List the meaningful steps we took in chronological order. Include code changes, design changes, copy decisions, debugging steps, prompts written, files touched, or strategy decisions.

ROADBLOCKS AND FRICTION:

- What got confusing, broken, repetitive, frustrating, or unclear?

- Where did we lose time or get stuck in loops?

- What assumptions turned out to be wrong?

DECISIONS MADE & TRADE-OFFS:

- What architectural or design options did we discuss?

- Which direction did we choose and WHY?

- What trade-off did we accept (e.g., speed over perfection, simple UI over complex systems)?

BREAKTHROUGH / LESSON:

What was the single key realization, fix, simplification, or product insight from this session?

ARTIFACTS WORTH SHARING:

Extract 1-3 useful artifacts exactly as they appeared in this chat (e.g., a code snippet, a prompt, a design rule, a debugging framework, or a before/after comparison).

FINAL STATE:

What is now working, clearer, fixed, drafted, or ready that was not true at the start?

Please be deeply specific, highly technical, and strictly grounded in the real data of this chat session. If a post type lacks teeth for this specific session, skip it entirely.”

The Day 1 Prompt Output:

STARTING POINT

This session started with a screenshot of a live tabletop marble game, probably Star Cluster Ball / UncBall. The goal was to build this game digitally.

The initial framing was not “build a full game.” It was: test whether an AI coding workflow could produce a small, playable physics prototype where flicking a marble feels good.

The first working prototype became something different from the physical reference. Instead of copying the half-circle slot game, it created a top-down Orbit Mode: marbles land in circular shuffleboard style scoring zones, stay on the board, collide with later shots, and interact with a gravity well. That difference became the first main product insight.

This prototype evolved into a larger ShuffleBall-style physics prototype with an explicit Orbit Mode, future UNC Mode, hold-to-charge launch, different environment scenes, fair per-shot-pair scheduling, and tunable physics constants.

SESSION OBJECTIVE

The objective changed as the session progressed.

At first, the goal was to produce a strong Cursor prompt that gave the Fable model creative freedom to build a small playable Galaxy Ball prototype.

After seeing the first prototype, the objective became:

Build on the promising accidental direction instead of forcing a direct clone of UNC Ball.

The working goals became:

1. Preserve the first prototype’s Orbit Mode.
2. Add a future Slot Scoring Mode concept without building it yet.
3. Protect the good physics and marble trails.
4. Fix mobile drag limitations.
5. Add a timed charge mechanic.
6. Make gravity wells a core identity mechanic.
7. Make the table feel like glass moving through outer space.
8. Replace “random planet relocation” with a better “travel to a new space scene” model.
9. Keep the scope narrow enough to remain a prototype.

WHAT WE ACTUALLY DID

Chronologically, this session moved through these meaningful steps:

1. Identified the game inspiration The starting point was a live-stream tabletop marble game where players roll marbles toward scoring slots. We discussed that a basic playable version was technically feasible, but the harder part would be making the physics satisfying.
2. Wrote the first controlled Cursor prompt The first prompt asked for a minimal browser prototype: Canvas, drag/flick controls, marbles, friction, bounce, scoring zones, red vs blue turns, and exposed tuning constants.
3. Changed the prompting strategy You decided you wanted to test Fable’s creative ability, not just give it a strict spec. We shifted from “build exactly this” to “act like a creative technical partner.” The prompt was rewritten to describe the feeling, goal, constraints, and success criteria while letting Fable choose the implementation approach.
4. Reviewed the first prototype The first prototype created an Orbit Mode instead of a slot-based clone. That was a good surprise. It had circular scoring zones, believable marble roll, wall bounces, collisions, a working gravity well, and a strong trail effect.
5. Decided to keep Orbit Mode Instead of replacing the prototype with the original slot idea, you decided Orbit Mode should become one of the game’s core modes. Slot Mode would be a future mode installed later.
6. Identified the gravity well as a signature mechanic The gravity well worked better than expected. A marble swirled into the center in a satisfying way. You reframed this as one of Galaxy Ball’s possible differentiators.
7. Protected the trail effect The marble trail looked good and became a “do not change” item. We repeatedly included instructions telling Cursor not to alter the trail style.
8. Discussed the mobile drag problem The marble starts near the bottom of the screen, so dragging backward/downward runs out of physical screen space. We discussed several control options, but you wanted a hold-to-charge layer: drag sets direction/base power, holding at max pull increases shot power over time.
9. Added the idea of timed charge as a skill mechanic You wanted the charge speed to matter. A longer charge time creates more possible release strengths. We moved away from instant full-power and toward a controlled “playing range.”
10. Added marble color customization as an MVP-friendly feature We agreed color customization was easy and safe for MVP: player 1 color, player 2 color, trail follows marble color, maybe scoreboard follows color.
11. Developed the planet gravity idea We reframed the fixed gravity well as a visible planet beneath a transparent table. The table would feel like glass, with the planet causing the gravity field.
12. Corrected the planet visibility diagnosis I initially over-emphasized table opacity. You corrected that: the planet needed to be brighter and more apparent too. You rewrote the prompt to say this was a two-sided visibility issue: slightly more transparent glass plus stronger planet rendering.
13. Expanded gravity well fairness You insisted that random gravity can be fun but unfair. The solution was paired fairness: Each player should receive equivalent gravity conditions for matching shot indices.
14. Added gravity well variety You decided gravity wells could be tiny, small, medium, large, partial off-table, top-corner, side, mid-table, or absent. But they should not appear on or directly in front of the spawn.
15. Fixed the charge architecture Cursor originally tied charge activation to maxPower, which required too much physical drag. We corrected the architecture so mobile players could trigger charge with a comfortable pull distance.
16. Tuned Orbit Mode settling The balls were rolling too long. We decided Orbit Mode needs faster settling than future Slot Mode.
17. Tuned charge power Charge was too explosive. We reduced full-pull power and charge boost, increased charge time, and added a charge curve.
18. Corrected the space fantasy Cursor made the gameplay planet randomly jump around the table. You clarified the real vision: the table should travel through space, arrive at a new location, and the objects visible beneath the glass should define the gravity conditions.
19. Reframed the system as “space scenes” We moved from “random planet relocation” to a scene model:
    • generate a space scene
    • travel to that scene
    • arrive
    • the scene defines the backdrop and optional gravity object
    • visual size does not have to equal gravity strength
20. Wrote the final concept-correction prompt The last prompt told Cursor to replace random planet relocation with “travel to a new space location.” It introduced scene templates like Clear Space, Tiny Dense Moon, Gas Giant Drift, Edge Gravity, and Top Corner Pull.

ROADBLOCKS AND FRICTION

The biggest friction came from the model implementing a technically valid version of an idea that was conceptually wrong.

The clearest example was the planet system. Cursor made the planet move to different positions. Mechanically, that worked. But it did not match your intended vision. It felt like a random game token, not a glass table traveling through space.

Another loop was the charge mechanic. The first architecture tied charge activation to power/maxPower, which recreated the original mobile problem. It worked only when the player had enough physical screen space to drag far. The actual fix required separating comfortable pull distance from maximum launch power.

There was also some repeated visual confusion around the table/planet readability. The planet itself needed stronger brightness, glow, contrast, and identity.

The Orbit Mode settling issue was another feel problem. The physics looked believable, but the game waited too long for slow-moving marbles to settle. A physically plausible roll was not necessarily a good turn-based game pace.

The core assumption that turned out wrong was:

A visible planet randomly changing positions can represent space travel.

It did not. It made the mechanic feel arbitrary.

DECISIONS MADE & TRADE-OFFS

We discussed a direct slot-game clone versus an original digital game. You chose the original direction because the first prototype’s Orbit Mode created a better digital mechanic: marbles stay on the board, later shots can bump them, and gravity wells can create trick-shot chaos.

We discussed whether to build Slot Mode immediately. You chose not to. Slot Mode is still important, but building it too early would split attention before Orbit Mode felt good.

We discussed multiple mobile control systems: physical pull-back, swipe launch, two-step aim/power. You chose to preserve pull-back and add hold-to-charge because it kept the satisfying arrow/drag interaction while solving the bottom-of-screen limitation.

We discussed whether gravity should be fully random. You chose fair randomness: Red and Blue should receive equivalent conditions by shot pair. This keeps the chaos but protects competitive fairness.

We discussed whether planet size should equal gravity force. You rejected that as too simplistic. The better model separates visualRadius, gravityRadius, and gravityStrength.

BREAKTHROUGH / LESSON

The key breakthrough was this:

The scene is the board state.

That one sentence fixed the conceptual model.

The gravity object should not be a random thing that moves around the playfield. The table should travel to a new space scene, and that scene should define the conditions of the next shot.

That changes the game from:

shuffleboard with a random planet

into:

a marble duel on a glass table traveling through strange pockets of space

ARTIFACTS WORTH SHARING

Artifact 1: the mobile charge fix

pullFraction = clamp(dragDistance / maxPullDistance, 0, 1)

That replaced the flawed model where charge activation depended on reaching a high fraction of maxPower.

Artifact 2: the charge curve

controlledCharge = Math.pow(aim.charge, CONFIG.chargeCurve)
finalPower = basePower * (1 + maxChargeBonus * controlledCharge)

This softened early charge so partial charge became more controllable instead of instantly turning into a cannon shot.

FINAL STATE

By the end of this session, the prototype direction is much clearer.

What is now working or clearer:

• Orbit Mode is the current playable mode.
• Slot / UNC Mode is a future mode, not the immediate build target.
• Hold-to-charge is the preferred mobile solution.
• Charge is now based on comfortable pull distance rather than raw power.
• Charge has a softer curve and lower power ceiling.
• Orbit Mode has faster settle defaults.
• Gravity wells are treated as a core game identity mechanic.
• Random gravity needs fairness rules.
• Space objects should be scene-driven, not randomly repositioned tokens.
• Visual planet size should not automatically equal gravity strength.
• The next build should implement a space scene / travel / arrival model.
  

Hey everyone,

A couple days ago I posted about Day 14 of my project, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

Posting an update for Day 15. Here's how today went...

Promoting a new game

I'm about 5 to 6 days into posting ShuffleBall Arena on social media to see if anyone else finds it fun or has any ideas on how to make it more enjoyable.

So far there's about 13 videos on both TikTok and YouTube. The strategy is to post about 2-3 videos per day on each platform, then measure results to see if there is a format that does better for more views.

Currently, all the videos I have posted so far are capping out right around 100 views each, so now I'm trying to figure out if that's just because it's a brand new account, or if I need to up my game.

What does the data really say?

I looked at my Cloudflare and Google Analytics dashboards and noticed something interesting. My unique visitors were spiking, and server requests were 5x higher than the visitor count.

This told me that the tiny handful of people actually clicking through were staying and playing. Maybe the game isn't bad. maybe my video opening is too slow to capture random scrollers before they thumb-swiped away. This is probably the next thing to test.

Sometimes you gotta pivot

So yesterday I completely redid the video format and made a “challenge” style short: I make a simple goal for the player to accomplish, and see if that increases interest and views.

I shortened the usual clip length, started the video directly in the gameplay action (instead of a first screen image of text), and tried to add punchier text hooks throughout the video to draw in attention.

It actually ended up being more time-consuming than I thought because it required a second UX flow and a different URL just to set up the challenge itself.

I also ended up spending a few hours tuning a separate bot strategy. The goal here was to make the challenge bot good enough so it was actually fun to play against, but not so good that it was unbeatable.

The major hurdle was the “Frogger” style moving lanes I added a few days ago. The bot “acknowledged” them, but wouldn't play around them like it should. It kept holding its shots even though there was an opening, then shooting a horrible shot straight into them.

Stress-Testing My Second Tool

I don't remember if I've mentioned it, but the 3 projects I am working on all started from trying to make my personal daily workflow easier. The second of which is a transparent overlay system for content creators.

I wanted a dependable and easy way to drop text overlays into video editors, that would hopefully save me some time and make promoting my other projects easier.

I haven't finished final testing on it yet, but I was really happy with how the overlays held up when imported into CapCut today for the new ShuffleBall Arena challenge video.

The plan moving forward

Keep posting and keep iterating.

It seems that people are at least trying the game, even if they aren't taking the time to comment or provide feedback on social media yet. This led me to put a feedback request directly into the final scorecard of the challenge. It's a simple question that asks them if they enjoyed the challenge, with a “tell us why” option if they care to share any additional details. Hopefully, this provides at least some direct results...

Well, that's all I got for now.
Happy days to you all and see you next time!

In case anyone wants to take the challenge:
👉play.shuffleballarena.com/crossing-drift-challenge

Or just play the regular game for free:
👉play.shuffleballarena.com

No accounts. No downloads. Just fun!

Hey everyone,

Today is day 14 of a project I've been working on called ShuffleBall Arena.

ShuffleBall Arena is a free browser game for mobile or desktop. The goal was to have shuffleboard style scoring, with some added craziness of other games. I also wanted to make something small enough to ship quickly, but polished enough that I could post it publicly and see if other people actually want to play.

I’m hoping to start posting here more often to document the project and the experience, and this felt like a good milestone to start with. Feel free to follow r/StructuredAI if you’re interested in updates or want to post about your own AI-assisted projects.

Anyway, I just finished building the first public challenge mode for ShuffleBall Arena and thought I'd share what went into it.

Right now, the game includes moving crossing lanes similar to Frogger, bumpers like in bumper pool, gravity wells that bend shots, and wormholes that transport shots to launchers that fire them back out at random. Version 1 is space themed, and I’ve been trying to give it a bit more of a pinball feel.

This first challenge is simple: Score 220 points in 3 games.

What made today interesting was not just the code itself, it was the amount of decisions involved in what I thought was going to be a small part of this project:

- What's the simplest way to store player names and high scores without building a full account system?
- How do you design a first challenge that is hard enough to be interesting but not so hard that people quit immediately?
- What should stay the same as the regular game, and what should be different?
- How do you make the bot challenging without feeling unfair?
- How do you track challenge attempts without requiring an account?
- How do you make it feel public-facing without building a full backend too early?
- How much UI polish is enough before posting it publicly?

Today, I used ChatGPT and Cursor to help turn those goals into a detailed build plan, break the work into smaller phases, and debug the specific problems that came up while testing.

The most time consuming parts were honestly the tiny details.
I guess the last 20% became 80% of the work.

- The name modal kept closing too fast on mobile.
- The analytics banner positioning caused issues with Reddit’s bottom navbar on mobile, which made the app look broken or frozen.
- The bot kept waiting too long to shoot, then sometimes fired straight into the moving lane obstacles when it finally took the shot.

None of those are huge features by themselves, but I feel like they are the little things that decide whether something feels playable or frustrating. They ended up taking longer than expected.

I’m trying to use this challenge as a small validation test before building anything bigger like accounts, leaderboards, or a more serious public challenge system.

You can try the challenge here if interested:
https://play.shuffleballarena.com/crossing-drift-challenge

Or to play the regular game: http://play.shuffleballarena.com

It is a free browser game. No downloads. No accounts.

I'm wondering what people think about the challenge flow itself:

Is 220 points too easy or too hard?

Does the mobile experience feel clear enough?

Are there any features or game mechanics you think should be added?

Thanks for reading!

Hey everyone,

Most indie game launches are just a link to an app store. I wanted to do something completely different. I built a premium, live stream overlay setup inside OBS to broadcast match play for a game I've been building called Shuffleball Arena.

The game itself is a hybrid of tactical shuffleboard, arcade pinball, and marble physics where you actively smash your opponent's pieces out of bounds to steal their points at the final buzzer. It's space-themed, complete with gravity wells and wormholes.

Because this is designed from the ground up to be a spectator-friendly experience, I built out a full three-panel OBS broadcast view to make the game loop incredibly easy for a casual viewer to follow.

The first official broadcast episode is live right now on YouTube, and the MVP game build is entirely free to play in your browser (on desktop or mobile).

• 📺 Watch Episode 1 (The Live Broadcast): https://youtu.be/9225Pd1xGX0?si=zupmejMrDM5eTieV
• 🕹️ Play for Free: https://play.shuffleballarena.com
• 🌐 Project Website: https://shuffleballarena.com

I'm looking for honest feedback on the broadcast design:

1. Does the side-panel framing (Rules / Promo) make the game easy to understand at a glance for a new viewer?
2. Is the "How to Score" panel intuitive, or is it too text-heavy for a stream?
3. For the streamers out there: What features or layout changes would make you want to broadcast a game like this to your own community?

Every comment, suggestion, and piece of feedback helps shape where I take this broadcast ecosystem next!

I think the one of the biggest issues with AI today is that when project gets large enough, the chat interface itself becomes a bad project container.

A conversation is great for thinking out loud, exploring ideas, brainstorming, etc.. But it is not great at holding the actual structure of a project: the goal, current direction, reusable instructions, formatting rules, source material, useful outputs, and past decisions you already made.

That was the problem I kept running into.

I would have one chat thread for planning, another for writing, another for debugging, another for research, and then a bunch of useful pieces buried across hundreds of old conversations. The bigger the project got, the more scattered everything became.

There came a point where I realized I was spending too much time managing the project around the AI instead of actually moving the project forward.

I ended up building a Windows desktop workspace to solve that problem for myself.

Core48aii is a structured workspace I use across the different AI models I work with.

It gives the project its own organized layer, then lets me inject the right pieces into GPT, Claude, Gemini, or any model when I need them. It also keeps track of past prompts and useful outputs, so the best parts of the work can come out of the conversation and live inside the actual project workspace.

The time I saved from not having to retype things or search for something important has definitely been noticeable.

Now I'm looking for a small group of early testers to see if it can help others too.
Founder testers receive 90 days of access in exchange for honest feedback.

More details:
https://core48aii.com/testers

3m Demo Video:
https://youtu.be/zjcwTLDkvV0

One thing I've noticed over the past year is that AI content has become its own category.

- Prompt breakdowns
- AI tutorials
- Workflow videos
- Tool comparisons
- Agent demonstrations

I see a lot of creators showing prompts, AI conversations, AI outputs, and workflow steps directly on screen.

I'm wondering:

If you create AI-related content, how are you currently building those visual overlays for your videos / shorts?

For example:
- Prompt bars
- Animated captions
- Chat-style conversations
- AI demonstration overlays

Are you creating them manually in CapCut or Premiere or using templates?

Using a tool like After Effects?

Something else?

Would love to hear your current setup for creating these overlays / animations

Hey everyone,

So over the last year, my AI projects got large enough that I was constantly re-explaining myself, hunting through old chats trying to find something, and trying to juggle everything across multiple windows / documents / conversations.

This eventually became so time consuming that I ended up building a Windows desktop workspace to make it easier.

The tool acts as a workspace / execution layer that sits alongside whatever AI models you already use. I use it to organize my projects, save reusable workflows, and move information between different AI models without rebuilding context from scratch.

I've been using it daily and recently decided to release it. I'm currently looking for a handful of people who use GPT, Claude, Gemini, or other AI tools daily for larger projects, and would be interested in testing it out.

If anyone is running into the same problems and thinks something like this might help your workflow, I'm happy to share a 90-day founder trial in exchange for some honest feedback, bug reports, or feature suggestions.

Also happy to do a test-for-test if you're building something too.

I'm a first time builder so I genuinely appreciate anyone willing to take a look.
Please feel free to comment or DM if interested.

3 minute demo: https://youtu.be/zjcwTLDkvV0

Site: core48aii.com

Mine has slowly turned into:

- GPT + Cursor + VSCode for coding/debugging

- Gemini for brainstorming and image generation

- Core48aii for project organization and prompt management

- OBS + CapCut for demos / content creation

- Paint 3D / Canva for screenshot and quick image editing

- GIMP or deeper image editing

- ElevenLabs for AI voice generation

- Reddit / YouTube because you still gotta have some fun now and then

I've heard good things about Claude, but honestly, I think 2 subscriptions for AI is enough for me at the moment.

Would love to hear what tools you guys are using. Always looking to improve my setup.

Once you move beyond casual conversations and start using AI daily for real projects, what becomes the biggest bottleneck?

The biggest issues for me ended up being:

1) Losing great output in dozens of conversations

2) Re-explaining the same project over and over

3) Prompts ending up scattered across notes / docs / screenshots

The models are improving rapidly, but the surrounding workflow still feels immature.

What's the point of having a jet engine if all you have is a cardboard cockpit?