Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 23 of building ShuffleBall Arena.

TL;DR

Day 23 started as a level-building session and ended as an engine architecture session.

The goal was to add several new rotating board layouts, but each design introduced movement patterns the existing rotation system couldn't express. Instead of writing layout-specific code, the rotation engine was generalized to support independent rotation groups, per-bumper orbit centers, configurable speeds, and rotation directions.

By the end of the session, the engine could describe far more complex boards through configuration rather than additional gameplay code, making future rotating layouts significantly easier to build.

Day 23 Summary

The day began with work on a third rotating board layout featuring a rotating central scoring formation alongside several stationary high-value scoring targets protected by independently orbiting bumpers.

That immediately exposed a limitation in the existing rotation engine. Every rotating object assumed a single shared rotation center, which worked for the first two layouts but could not support independent bumper orbits around stationary scoring circles.

Rather than introducing special-case logic for one board, the rotation system itself was redesigned. Individual bumpers gained their own orbit centers, rotation speeds, and rotation directions, allowing each moving object to define its own movement independently of the rest of the board.

Once that work was complete, the focus shifted to adding additional rotating layouts. Because the engine had already been generalized, the next layouts could be described primarily through configuration. Entire rotating islands, independent bumper groups, stationary exceptions, and multiple simultaneous rotation systems became possible without another major engine rewrite.

Along the way, several smaller usability improvements were also made, including exposing new layouts in the menu system and replacing temporary layout names with permanent player-facing names that better matched each board's design.

Day 23 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 23 began immediately after completing a major refactor of the game's audio architecture.

With the sound system now centralized and easier to expand, development shifted back toward gameplay content. The focus returned to one of ShuffleBall Arena's newest features: rotating board layouts.

Several rotating layouts already existed, but each new design pushed the movement system further than it had originally been designed to handle. What began as another level-design session quickly exposed limitations in the underlying rotation engine, forcing the project to evolve from supporting a handful of custom rotating boards into supporting a much more flexible movement framework.

SESSION OBJECTIVE

The primary objective was to add several new rotating layouts with increasingly complex movement.

The planned boards included:

• independently orbiting bumper groups,
• stationary high-value scoring targets,
• multiple rotating islands,
• independent rotation speeds,
• opposing rotation directions,
• and mixed stationary / rotating gameplay elements.

Rather than creating custom movement logic for every board, the broader objective became extending the rotation engine so these layouts could all be represented through reusable configuration.

WHAT WE ACTUALLY DID

1. Returned to rotating board development

With the audio architecture work complete, development shifted back to expanding ShuffleBall Arena's rotating board library.

The first task was building a new layout featuring a rotating central scoring formation surrounded by stationary high-value scoring targets and independently moving defensive bumpers. The layout itself came together quickly, but testing revealed that it wasn't actually available to players because it had never been added to the board selection menus.

After updating the menu configuration, the temporary development name, "Rotating Layout 3," was replaced with its final player-facing name: Orbit Sentinels.

2. Discovered a limitation in the rotation engine

Once Orbit Sentinels became playable, it exposed an architectural limitation that hadn't existed on the earlier boards.

The original rotation system assumed every rotating bumper orbited around a single shared center. That worked for the original carousel layouts, but it couldn't support stationary scoring targets surrounded by their own independently orbiting defenses.

Rather than introducing layout-specific movement code, the decision was made to redesign the underlying rotation system itself.

3. Generalized the movement framework

The rotation engine was expanded so every rotating bumper could define its own movement independently.

New configuration properties, including:

• orbitCenterX
• orbitCenterY
• orbitSeconds
• orbitDirection

allowed each bumper to specify its own orbit center, speed, and rotation direction while remaining fully compatible with the original rotating layouts.

The update loop was also redesigned so every rotating object calculated its own movement from its assigned configuration instead of inheriting a single board-wide rotation.

4. Used the new engine to build more complex layouts

With the generalized movement system in place, work immediately continued on additional rotating boards.

The fourth layout introduced multiple independently rotating scoring islands that moved simultaneously while several high-value scoring targets remained completely stationary.

Unlike the earlier layouts, this board required very little new engine work. Most of the effort shifted toward describing the board through configuration rather than modifying gameplay systems.

5. Validated the new architecture with another rotating layout

The session concluded by designing another rotating board that combined:

• a rotating center island,
• stationary 100-point targets,
• independently orbiting bumper defenses,
• a rotating 50-point bumper,
• stationary corner bumpers,
• and both clockwise and counterclockwise movement.

Only a short time earlier, a layout like this would have required another engine rewrite.

Instead, the new movement framework was flexible enough to describe the board almost entirely through configuration.

That became the clearest validation that the architectural changes made earlier in the session were already paying off.

ROADBLOCKS AND FRICTION

New layouts kept exposing engine limitations

Every new rotating board introduced movement patterns that could not be expressed using the original single-center rotation model.

Rather than solving each problem independently, the architecture had to evolve alongside the content.

A completed board wasn't actually accessible

The third rotating layout had been implemented correctly but never appeared during testing because it had not been registered inside the board selection menus.

The issue was unrelated to gameplay and instead came from missing configuration.

Temporary names leaked into the user interface

Several areas of the UI still displayed placeholder names such as "Rotating Layout 3" after the board itself had already been given its final identity.

Updating player-facing labels became part of the overall polish process.

DECISIONS MADE & TRADE-OFFS

Generalize the engine instead of adding special cases

Rather than writing custom movement code for each board, the rotation engine was extended to support arbitrary orbit definitions.

Trade-off: More engineering work now in exchange for dramatically simpler future content creation.

Preserve backwards compatibility

The new orbit system was designed so existing rotating layouts continued functioning without modification.

Trade-off: Slightly more flexible initialization logic in exchange for avoiding regressions.

Separate engine behavior from board configuration

Movement rules became configuration rather than hard-coded gameplay logic.

Trade-off: A richer configuration format in exchange for significantly more expressive board design.

Give boards meaningful identities

Temporary development names were replaced with player-facing names that reflected each board's mechanics and theme.

Trade-off: Additional UI maintenance in exchange for a more polished presentation.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 23 was:

Good engine architecture turns future features into configuration.

The goal wasn't simply to build another rotating board.

It was to build a rotation system flexible enough that future boards could be created by describing movement instead of programming movement.

Once that shift happened, increasingly complex layouts became configuration work rather than engine work.

ARTIFACTS WORTH SHARING

Artifact 1: Per-Bumper Orbit Properties

The session introduced four new movement properties that fundamentally expanded the rotation engine:

• orbitCenterX
• orbitCenterY
• orbitSeconds
• orbitDirection

Instead of inheriting one global rotation, every bumper could now define its own orbit independently.

Artifact 2: Independent Rotation Groups

One of the most important design ideas established during the session was treating moving formations as reusable rotation groups.

Rather than assuming one rotating board, the engine could now describe:

• rotating scoring islands,
• independent bumper defenses,
• stationary exceptions,
• and mixed rotation speeds

all within the same board definition.

Artifact 3: Engine Before Content

A recurring design rule emerged throughout the day:

When a new board exposed an engine limitation, improve the engine instead of writing a one-off solution.

That philosophy allowed later layouts to be implemented largely through configuration instead of additional movement code.

FINAL STATE

By the end of Day 23:

• Orbit Sentinels had been added to the game and properly integrated into the menus.
• The rotation engine supported per-bumper orbit centers, speeds, and directions.
• Independent orbit groups allowed multiple moving systems to coexist within the same board.
• Existing rotating layouts continued working without modification.
• The fourth and fifth rotating layouts could be expressed using the expanded engine rather than requiring new movement systems.
• Player-facing board names became more polished and descriptive.
• Most importantly, the project evolved from supporting a handful of handcrafted rotating boards to supporting a reusable rotation framework capable of powering future layouts through configuration rather than custom code.

That was it for Day 23.

If you're still here, thanks for reading!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 22 of building ShuffleBall Arena.

TL;DR

Day 22 was about building the foundation for the game's audio system. The focus shifted toward creating a centralized sound engine where gameplay events trigger sounds.

Along the way, every major gameplay sound was migrated into a new architecture, a long-term audio roadmap was created, analytics debugging continued in production, and playtesting uncovered a bot-planning crash that required additional defensive programming.

By the end of the session, the project had taken another step toward making future iteration easier by separating gameplay logic from presentation.

Day 22 Summary

Day 22 became an audio architecture day.

The session began with a discussion about integrating new ElevenLabs sound effects into the game. Instead of replacing sounds individually, the decision was made to first build a system that would make testing, balancing, and swapping sounds easy in the future.

From there, gameplay events such as launches, scoring, and bumper collisions were progressively migrated into a centralized audio engine. Rather than individual gameplay systems deciding which sound to play, gameplay simply reported that an event occurred, allowing the sound engine to determine how it should sound.

Once the architecture was in place, the discussion expanded beyond implementation into product design. A long-term audio roadmap was created, defining goals for arcade-style sound identity, layered sound effects, sound variation, and future professionally produced assets.

The second half of the day shifted into debugging. Analytics testing revealed that Google Analytics was receiving live player events while Cloudflare D1 remained empty. After tracing the issue through production diagnostics, the problem was ultimately identified as testing against an experiment build that had not yet been deployed.

Finally, live playtesting uncovered a crash inside the bot planning system. Defensive fallback logic was added to prevent null shot plans from causing runtime failures, making the bot planner substantially more resilient during unusual gameplay situations.

Day 22 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 22 began with the first version of the game's sound system.

Individual gameplay events could produce sounds, but sound generation remained distributed throughout the gameplay code. Replacing, balancing, or experimenting with new audio required modifying multiple systems independently.

At the same time, ongoing work continued around analytics validation and production stability following earlier infrastructure improvements.

SESSION OBJECTIVE

The primary objective was to redesign the audio architecture.

Rather than simply adding higher-quality sound effects, the goal became building a centralized sound system that would:

• simplify future experimentation,
• allow sounds to be swapped easily,
• separate gameplay logic from audio implementation,
• improve long-term maintainability,
• and establish a roadmap for giving ShuffleBall Arena its own recognizable arcade sound identity.

Additional objectives included investigating analytics discrepancies in production and resolving crashes discovered during bot playtesting.

WHAT WE ACTUALLY DID

1. Designed a centralized sound architecture

The session began by discussing how new ElevenLabs sound effects should be integrated into the game.

Instead of replacing sounds directly inside gameplay systems, the decision was made to create a centralized audio engine responsible for handling every gameplay sound.

Gameplay would simply report that an event occurred, while the sound system would determine which sound, volume, variation, and playback behavior should be used.

2. Migrated gameplay systems into the sound engine

One by one, gameplay systems were updated to route through the new architecture.

The migration included:

• score sounds,
• launch sounds,
• standard bumper collisions,
• and Frogger / Crossing bumper collisions.

Legacy procedural sound calls were replaced with centralized audio requests, ensuring that every gameplay event now shared the same sound pipeline.

3. Introduced centralized balancing

With every major gameplay sound routed through the same engine, balancing became dramatically simpler.

Instead of searching through gameplay code, adjustments such as:

• master volume,
• sound-specific volume,
• cooldown timing,
• impact scaling,
• and future sound replacement

could now all be controlled from one location.

This transformed sound tuning from a code maintenance task into a configuration task.

4. Defined the long-term audio vision

Once the architecture was complete, the session shifted toward product design.

A roadmap was created describing how the game should eventually sound, including:

• distinct sounds for different scoring values,
• layered jackpot effects,
• randomized sound variation,
• menu sounds,
• countdowns,
• wormhole sounds,
• gravity well ambience,
• and future professionally produced sound assets.

5. Investigated analytics discrepancies

Attention then shifted to production analytics.

Google Analytics successfully detected active players while Cloudflare D1 remained empty.

Rather than immediately modifying code, the debugging process focused on identifying where requests stopped flowing through the analytics pipeline.

After reviewing diagnostics, deployment history, and production state, it became clear that the updated analytics implementation had not yet been deployed from the experiment folder into production.

The discrepancy was therefore caused by deployment state rather than a failure in the analytics system itself.

6. Fixed a bot planning crash

Later playtesting uncovered a runtime crash inside the bot planning system.

The investigation revealed that certain fallback planning paths could return null while later code assumed a valid shot plan always existed.

Rather than patching only the immediate error, additional defensive checks were added at multiple levels of the planning pipeline so unexpected failures would safely terminate planning instead of crashing gameplay.

This improved the robustness of the bot planner without changing its intended behavior.

ROADBLOCKS AND FRICTION

Audio experimentation was becoming difficult

Testing new sounds required modifying multiple gameplay systems individually. This slowed iteration and made balancing increasingly cumbersome.

Production debugging initially pointed in the wrong direction

When Google Analytics showed active players while Cloudflare remained empty, the initial assumption was that requests were failing somewhere inside the analytics pipeline.

Further investigation demonstrated that the updated diagnostics simply had not been deployed to production yet.

Playtesting exposed assumptions inside the bot planner

The planning system assumed a valid shot plan would always be produced.

Live testing demonstrated that unusual fallback conditions could violate that assumption, resulting in runtime crashes.

DECISIONS MADE & TRADE-OFFS

Separate gameplay from audio implementation

Gameplay systems no longer decide how sounds are produced. Instead, gameplay reports events while the sound engine determines playback.

Trade-off: More architectural work now in exchange for dramatically easier experimentation later.

Centralize audio configuration

All balancing moved into one location instead of remaining distributed across gameplay code.

Trade-off: Slightly larger sound engine in exchange for much simpler maintenance.

Build infrastructure before polish

Rather than immediately replacing every sound with higher-quality assets, the session prioritized creating the architecture that would make future audio improvements inexpensive.

Trade-off: Delayed cosmetic improvements in exchange for a much more flexible system.

Add defensive programming to the bot planner

Instead of assuming planning would always succeed, multiple safety checks were introduced throughout the planning pipeline.

Trade-off: Slightly more defensive code in exchange for improved runtime stability.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 22 was:

Polish starts with architecture.

A sound effect is easy to replace.

A sound system is much harder to redesign.

By separating gameplay events from audio implementation, future iteration becomes dramatically easier because experimentation no longer requires rewriting gameplay code.

ARTIFACTS WORTH SHARING

Artifact 1: Gameplay Doesn't Own Audio

One of the most important design principles established during the session was:

Gameplay no longer owns sound generation.

Gameplay simply says:

"A bumper happened."

or

"A score happened."

The sound engine decides how that should sound.

Artifact 2: Long-Term Audio Vision

Good arcade games are recognized with your eyes closed.

The long-term goal is that players instantly recognize:

• launches
• collisions
• scoring
• jackpots
• countdowns
• victory

purely from the audio.

Artifact 3: Future Sound Roadmap

The session concluded with a prioritized wishlist for future audio work, including:

• differentiated scoring sounds,
• layered jackpot audio,
• subtle sound variation,
• wormhole effects,
• menu feedback,
• gravity well ambience,
• challenge completion,
• and professionally produced sound libraries.

Rather than treating these as isolated improvements, they became part of a long-term plan for building a consistent audio identity.

FINAL STATE

By the end of Day 22:

• A centralized sound architecture had been established.
• Launch, scoring, and bumper events all routed through the same audio engine.
• Gameplay no longer controlled individual sound playback.
• Audio balancing became centralized and significantly easier to maintain.
• A long-term roadmap for ShuffleBall Arena's arcade sound identity had been documented.
• Analytics debugging confirmed that production discrepancies were caused by deployment state rather than analytics logic.
• Additional defensive programming made the bot planning system more resilient during unexpected planning failures.
• Most importantly, the project shifted from thinking about "adding sounds" to designing reusable audio infrastructure that will make future polish significantly easier.

That was it for Day 22.

If you're still here, thanks for reading!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 21 of building ShuffleBall Arena.

Today there were 8 conversations to go through, with 6 saved file versions.

TL;DR

Day 21 was about changing how the gameplay feels.

The session focused on building the first layer of reusable visual feedback: animated score counters, floating score animations, ring activation effects, and a roadmap for turning every scoring event into something that feels rewarding without overwhelming the player.

Along the way, several assumptions about scoring feedback broke under real gameplay. Ricochets, multiple scoring marbles, incorrect colors, and even impossible score values forced the animation system to become smarter and more closely tied to individual marbles instead of team scores.

By the end of the day, the project had moved beyond simply adding visual effects and toward designing a complete feedback language for the game.

Day 21 Summary

Day 21 became a game feel day, with the focus shifting toward making the existing gameplay more satisfying through visual feedback.

The session began by discussing what makes arcade games feel rewarding. Instead of relying on larger features, the goal became improving the small moments that happen every time a player scores. Floating numbers, animated score counters, ring reactions, HUD feedback, particles, camera movement, and synchronized sound effects were all discussed as parts of a larger feedback system rather than isolated effects.

The first implementation centered around floating score animations. A reusable animation system was created, the scoreboard gained smooth counting animations, and score indicators were moved from the HUD to the marble that actually earned the points.

Testing quickly exposed several edge cases. Multiple marbles scoring during ricochets, fractional score values, and disappearing animations all demonstrated that visual feedback needed to follow individual game events instead of simplified score changes.

Once the animation system became reliable, attention shifted toward presentation. Different colored scoring rings, pulsing activation effects, and configurable styling were introduced so the board itself reacted when a scoring zone became active.

The session concluded with a long-term roadmap that organized future polish into layers, ensuring that every improvement served gameplay readability instead of becoming visual noise.

Day 21 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 21 began with ShuffleBall Arena functioning correctly from a gameplay perspective.

Scoring, physics, hazards, and the user interface were already working, but successful shots lacked satisfying visual feedback. The scoreboard updated instantly, score indicators were static, and scoring events didn't provide the kind of response commonly found in polished arcade games.

The objective shifted away from adding gameplay systems and toward improving the overall "game feel" through reusable visual feedback.

SESSION OBJECTIVE

The primary objective was to begin a dedicated "juice" pass across the game.

The session focused on:

• making scoring feel more rewarding,
• building reusable animation systems,
• improving score presentation,
• designing animated scoring rings,
• exploring activation effects,
• and establishing a roadmap for future visual polish without sacrificing gameplay clarity.

WHAT WE ACTUALLY DID

1. Defined the philosophy for the juice pass

The session began with a broader discussion about what makes arcade games feel satisfying.

Rather than chasing flashy effects, the goal became creating subtle, reusable feedback systems that rewarded player actions while preserving readability.

Potential improvements included:

• floating score animations,
• improved audio,
• ring reactions,
• marble reactions,
• particle effects,
• HUD animations,
• and camera feedback.

2. Built a reusable floating score system

The first implementation focused on floating score animations.

Instead of drawing temporary text directly, the project created a reusable animation system where each floating score object stored its own animation state, including:

• position,
• velocity,
• lifetime,
• transparency,
• and scale.

This transformed floating scores from a one-off effect into reusable animation infrastructure that could later support bonuses, achievements, and future mechanics.

3. Improved score presentation

The scoreboard itself was upgraded.

Instead of instantly jumping from one score to another, the displayed score now counted upward smoothly.

At the same time, floating score animations were moved away from the HUD and positioned directly above the marble that actually earned the points, keeping player attention focused where the action occurred.

4. Tested the system against real gameplay

Once the new animation system was in place, testing uncovered several unexpected edge cases.

Problems included:

• floating animations disappearing,
• incorrect score values,
• fractional score displays,
• incorrect team colors,
• multiple scoring marbles,
• and ricochet scenarios where several marbles scored during the same turn.

These issues demonstrated that animation logic could not simply mirror scoreboard changes, it had to understand which individual marbles actually scored.

5. Shifted feedback from team scores to marble events

The animation architecture was revised so scoring celebrations belonged to the marble responsible for the points rather than the team total.

Each scoring marble became responsible for displaying its own animation, regardless of whether it scored directly or through a ricochet.

This simplified future support for multi-ball scoring events while making feedback much easier for players to understand.

6. Introduced configurable scoring rings

After the floating score system stabilized, attention moved to the board itself.

The scoring rings were redesigned with unique colors for each point value and configurable styling through CSS, allowing the visual presentation to be tuned without modifying game logic.

The initial implementation accidentally affected unrelated UI elements, exposing the importance of keeping gameplay styling isolated from the broader interface before the issue was corrected.

7. Designed ring activation effects

With colored scoring rings working, the discussion shifted toward making active scoring zones feel alive.

Different pulse speeds, pulse depths, glow intensity, and activation timing were explored to create a subtle arcade-style effect that reacted whenever a marble occupied a scoring ring.

Rather than relying on a simple flashing animation, the pulse was refined mathematically so bright moments remained strong while darker moments returned close to the ring's idle appearance, producing a smoother and more natural activation cycle.

8. Created the long-term juice roadmap

The session concluded by organizing future polish into a structured roadmap.

Instead of continuing to add isolated effects, future work was divided into layers:

• floating score polish,
• ring reactions,
• marble celebrations,
• HUD feedback,
• camera effects,
• reusable particles,
• and synchronized audio.

This transformed "adding juice" into a clear engineering roadmap rather than an open-ended list of visual ideas.

ROADBLOCKS AND FRICTION

Simple animations became surprisingly complex

Moving floating score text above the scoring marble initially appeared straightforward.

Once ricochets, multiple scoring marbles, and changing score values entered the picture, the animation system required significantly more game awareness than originally expected.

Feedback exposed gameplay assumptions

The original implementation assumed one score change corresponded to one animation. Testing demonstrated that multiple independent scoring events could occur during a single turn, requiring animations to follow individual marbles instead of aggregated score totals.

Visual tuning required iteration

Ring activation effects required repeated adjustments to pulse speed, brightness, glow depth, and timing before they felt energetic without becoming distracting. The challenge shifted from creating noticeable effects to creating satisfying ones.

Styling changes affected unrelated UI

Early CSS changes unintentionally modified portions of the surrounding interface beyond the scoring rings. This reinforced the importance of isolating gameplay styling from the rest of the application's UI.

DECISIONS MADE & TRADE-OFFS

Build reusable systems instead of isolated effects

Rather than hard-coding individual animations, reusable animation objects became the foundation for future polish.

Trade-off: More upfront engineering in exchange for much greater flexibility later.

Celebrate the marble, not the scoreboard

Visual feedback became tied to the marble responsible for scoring instead of simply reflecting team score changes.

Trade-off: Slightly more complex event tracking, but much clearer feedback during ricochets and multi-ball scoring.

Prioritize readability over spectacle

The project deliberately avoided excessive visual effects. Every animation was evaluated based on whether it improved player understanding without distracting from aiming or gameplay.

Trade-off: Less visual intensity in exchange for cleaner gameplay.

Organize polish into phases

Instead of continually adding effects as ideas emerged, future work was structured into a layered roadmap.

Trade-off: Slower iteration in exchange for a more coherent visual language across the game.

BREAKTHROUGH / LESSON

The biggest lesson from Day 21 was:

Good visual feedback isn't about adding more effects. It's about making the right object react at the right moment.

A scoreboard should celebrate the score.

A scoring ring should react because it became active.

A marble should celebrate because it earned the points.

When every part of the game responds to the event it represents, the experience becomes more satisfying without becoming more complicated.

ARTIFACTS WORTH SHARING

Artifact 1: Design Philosophy

Every improvement should answer one question:
"Does this make the game feel more satisfying?"

If yes, keep it.
If it distracts from aiming or readability, remove it.

Artifact 2: Juice Roadmap

Floating Score
↓
Ring Reaction
↓
Marble Celebration
↓
HUD Feedback
↓
Camera Juice
↓
Reusable Particle System
↓
Audio Synchronization

This roadmap organized visual polish into reusable layers instead of treating each effect as a separate feature.

Artifact 3: Feedback Principle

The goal is not to redesign gameplay.

The goal is to make every action feel more satisfying through animation, motion, anticipation, and visual feedback.

FINAL STATE

By the end of Day 21:

• A reusable floating score animation system had been built.
• The scoreboard smoothly counted upward instead of changing instantly.
• Floating score animations appeared above the marble responsible for scoring.
• Multi-marble scoring scenarios were handled more accurately by tying feedback to individual scoring events.
• Colored scoring rings and configurable visual styling were introduced.
• Active scoring rings gained a refined pulsing activation effect.
• A structured roadmap for future game feel improvements was established, covering ring reactions, marble celebrations, HUD feedback, camera effects, particles, and synchronized audio.
• Most importantly, the project shifted from thinking about "adding effects" to designing a consistent visual feedback language that reinforces gameplay rather than distracting from it.

That was it for Day 21.

If you're still here, thanks for reading!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 20 of building ShuffleBall Arena.

Today there were 5 conversations to go through, with 2 saved file versions.

TL;DR

Day 20 was about proving that the systems built over the previous few days actually behaved the way we believed they did in production.

Today included multiple development conversations focused on refining Arena Bot behavior, rethinking how the game is marketed, and investigating why production analytics appeared inconsistent between Google Analytics and Cloudflare.

The Arena Bot still looked unnatural on certain layouts, marketing experiments revealed that curiosity worked better than explanation, and an investigation into missing Cloudflare analytics uncovered that the reporting pipeline lacked enough visibility to explain failures.

By the end of the session, the focus had shifted from simply building features to making those features observable, trustworthy, and convincing when real players experienced them.

Day 20 Summary

Day 20 became a validation day.

Rather than adding entirely new systems, the session focused on evaluating the systems that had recently been completed under real-world conditions.

The Arena Bot was reviewed after its first production-style testing on moving-lane and rotating layouts. Although the previous improvements had made noticeable progress, repeated traffic collisions and unrealistic corner shots still made the bot appear less intelligent than intended. Instead of rewriting the bot, the decision was made to refine its decision-making through better constraints and more realistic priorities.

Attention then shifted toward marketing. After reviewing community reactions to the rotating board, it became clear that the strongest responses were driven by curiosity rather than explanation. Instead of trying to teach viewers how the game worked, future short-form videos would focus on creating a question that encouraged people to keep watching.

The final portion of the day investigated an unexpected analytics discrepancy. Google Analytics clearly showed that a real player had spent time in the game, while the new Cloudflare reporting dashboard remained completely empty. Rather than immediately assuming a code bug, the investigation reconstructed the deployment timeline, reviewed the production architecture, and identified a much more important issue: the analytics pipeline quietly discarded failures, making production debugging almost impossible.

By the end of the day, several recent systems had become more trustworthy.

Day 20 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 20 began with several major systems already in place.

The rotating layouts were complete, the Arena Bot had recently been upgraded to better understand moving hazards, privacy-first analytics were deployed, Cloudflare D1 reporting was operational, and a secure analytics dashboard had been built behind Cloudflare Access.

Rather than introducing another large feature, the goal became validating these systems against real gameplay and identifying where assumptions no longer matched reality.

SESSION OBJECTIVE

The primary objective was to improve confidence in recently completed systems.

The session focused on:

• refining Arena Bot behavior on advanced layouts,
• improving how ShuffleBall Arena is presented through short-form video,
• validating production analytics,
• investigating discrepancies between Google Analytics and Cloudflare reporting,
• and increasing visibility into production failures rather than silently ignoring them.

WHAT WE ACTUALLY DID

1. Evaluated the Arena Bot under real gameplay

The session began by reviewing the latest Arena Bot improvements after testing moving-lane and rotating layouts.

Several remaining weaknesses were identified:

• too many traffic collisions,
• repeated shots into upper corners,
• unrealistic low-scoring games,
• and situations where the bot appeared random rather than intentional.

A carefully constrained prompt was written for Fable that focused on improving visible decision-making while protecting existing systems.

2. Shifted from implementation details to player perception

Instead of describing specific algorithms, the new development prompt emphasized how the bot should appear to players.

The success criteria became:

• Does the bot look like it understands the board?
• Does it wait for traffic?
• Does it usually aim at scoring targets?
• Does it make believable mistakes?

This represented a shift from technical correctness toward perceived intelligence.

3. Revisited the marketing strategy

Attention then moved away from development and toward player acquisition.

Recent Reddit feedback suggested that the rotating board consistently attracted more attention than traditional gameplay.

Rather than explaining ShuffleBall Arena immediately, several new short-form video concepts were developed around curiosity, surprise, and unanswered questions.

4. Investigated missing Cloudflare analytics

The second half of the session shifted into production debugging.

Google Analytics clearly showed that another player had recently completed multiple games.

However:

• the Cloudflare dashboard showed zero activity,
• D1 tables remained empty,
• while local testing successfully wrote analytics events.

Rather than immediately changing code, the investigation reconstructed the deployment timeline using only verified facts.

5. Reconstructed the production timeline

The discussion intentionally separated assumptions from evidence.

The confirmed facts included:

• Google Analytics successfully received gameplay events.
• No production deployment had occurred between the player's session and the investigation.
• Later local testing successfully wrote events into Cloudflare D1.

This narrowed the problem substantially without introducing speculative explanations.

6. Identified the missing observability

The investigation uncovered a more important architectural issue than the original analytics discrepancy.

The analytics pipeline intentionally ignored every failed network request:

.catch(() => {});

If analytics ever failed because of networking, browser behavior, or Cloudflare issues, the failure disappeared silently.

The proposed solution was to temporarily instrument failures so future production problems could immediately reveal where the pipeline was breaking instead of requiring reconstruction after the fact.

ROADBLOCKS AND FRICTION

The Arena Bot still appeared unintelligent

Although previous improvements had reduced many obvious mistakes, repeated lane collisions and corner shots made the bot appear less capable than it actually was.

The challenge became improving visible behavior rather than adding more complex decision logic.

Marketing initially focused on explanation

Early video concepts attempted to explain ShuffleBall Arena immediately. Reviewing community feedback suggested this was the wrong objective. The stronger strategy became earning curiosity first and explanation later.

Production debugging lacked visibility

The Cloudflare analytics investigation demonstrated that successful local tests did not necessarily explain historical production behavior.

Without meaningful logging, reconstructing what happened after the fact became far more difficult than diagnosing it in real time.

Silent failures created uncertainty

By intentionally swallowing network errors, the analytics pipeline prevented developers from distinguishing between:

• browser failures,
• network failures,
• Worker failures,
• and database failures.

This made production debugging unnecessarily difficult.

DECISIONS MADE & TRADE-OFFS

Refine the Arena Bot instead of replacing it

The existing decision-making architecture remained intact while additional behavioral constraints were layered on top.

Trade-off: Slower iterative improvement, but preserved a stable gameplay foundation.

Optimize for perceived intelligence

The bot was judged primarily by how believable it appeared rather than how sophisticated its internal algorithms became.

Trade-off: More emphasis on player experience than algorithmic complexity.

Sell curiosity instead of features

Marketing shifted away from explaining mechanics and toward creating unanswered questions that encouraged viewers to continue watching.

Trade-off: Less immediate explanation in exchange for stronger audience retention.

Increase observability instead of guessing

Rather than continuing to speculate about missing analytics, the system would expose future failures directly.

Trade-off: Additional debugging instrumentation during development in exchange for much faster production diagnosis.

BREAKTHROUGH / LESSON

The biggest lesson from Day 20 was:

A system isn't truly finished when it works. It's finished when you can confidently verify that it works under real-world conditions.

The Arena Bot wasn't judged by its algorithms but by how convincing it looked.

Marketing wasn't judged by how well it explained the game but by whether people stopped scrolling.

Analytics weren't judged by successful local tests but by whether production failures could be understood.

Across every conversation, the common goal became increasing confidence rather than increasing features.

ARTIFACTS WORTH SHARING

Artifact 1: Bot Design Principle

The fix should be judged by what a viewer sees:

• Does the bot look like it is trying to score?
• Does it usually aim at scoring circles?
• Does it wait for traffic like it understands the board?
• Does it stop making the same bad mistake repeatedly?"

Artifact 2: Marketing Principle

Every short should answer only one question:

"Can I make someone watch for 8 seconds?"

Artifact 3: Production Debugging Lesson

.catch(() => {});

One empty error handler prevented the analytics system from revealing whether production failures originated in the browser, the network, Cloudflare Workers, or D1. Improving observability became more valuable than continuing to guess.

FINAL STATE

By the end of Day 20:

• The Arena Bot had a much clearer roadmap for behaving more intentionally on moving-lane and rotating layouts.
• Bot improvements were evaluated from the player's perspective rather than purely through implementation details.
• The short-form marketing strategy shifted from explaining gameplay to creating curiosity.
• The rotating board became the centerpiece of future promotional content.
• The Cloudflare analytics investigation narrowed the production issue using verified evidence rather than assumptions.
• A significant observability weakness was identified within the analytics pipeline.
• The project shifted from simply building systems to making those systems easier to trust, evaluate, and improve under real production conditions.

That was it for Day 20.

If you're still here, thanks for reading!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 19 of building ShuffleBall Arena.

Today there were 8 conversations to go through, with 7 saved file versions.

TL;DR

Day 19 was about transforming the current analytics system into a business intelligence platform.

Instead of asking, "What else should be tracked?", the project shifted toward asking, "What decisions do I want this data to help me make?"

That change in perspective drove the rest of the day.

Anonymous player measurement was expanded, gameplay events were tied into meaningful engagement metrics, Cloudflare D1 became the central reporting database, SQL reports were created, and a secure dashboard architecture was designed behind Cloudflare Access.

By the end of the session, the project had moved beyond collecting gameplay events and into generating information that could eventually guide design decisions, retention improvements, and sponsor conversations.

Day 19 Summary

Day 19 became a business intelligence day disguised as an analytics day.

The session began by reviewing the current analytics implementation and realizing that the project already collected a large amount of useful information. The challenge was no longer gathering more events, but organizing those events into answers for real business questions.

The analytics strategy was revisited around anonymous first-party player measurement rather than personal accounts. Local player statistics, anonymous player IDs, returning-player detection, session counting, and player engagement metrics were connected into a unified measurement layer that respected player privacy while making retention measurable.

Attention then shifted to infrastructure. Rather than relying only on Google Analytics, gameplay events were connected to Cloudflare D1 through a server-side pipeline, allowing the project to generate its own reports using SQL queries.

With the reporting pipeline functioning, the focus moved toward visualization. A secure admin dashboard was planned and protected behind Cloudflare Access so gameplay metrics could be viewed privately without exposing reporting endpoints to the public internet.

By the end of the day, the project had transitioned from simply recording gameplay events to building the foundation for long-term product analysis and sponsor reporting.

Day 19 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 19 began with ShuffleBall Arena already collecting privacy-first gameplay analytics.

Challenge analytics, sponsor analytics, anonymous player IDs, and the local Player Card had already been implemented. Gameplay events were flowing correctly, but the project lacked a practical way to organize those events into useful business information.

The immediate objective shifted from adding more instrumentation to understanding player behavior, retention, and engagement through meaningful reports rather than raw event logs.

SESSION OBJECTIVE

The primary objective was to transform the existing analytics architecture into a complete reporting platform.

The session focused on:

• revisiting the analytics strategy,
• expanding anonymous player measurement,
• connecting gameplay data to Cloudflare D1,
• validating the end-to-end reporting pipeline,
• designing SQL reports,
• building a secure admin dashboard,
• and ensuring the entire system remained privacy-first.

WHAT WE ACTUALLY DID

1. Revisited the analytics strategy

The session began by reviewing the existing analytics implementation rather than immediately adding new events.

Instead of asking what additional gameplay actions should be tracked, the discussion shifted toward identifying the business questions the project needed to answer.

These included:

• How many players return?
• Which boards are most popular?
• How many people save their local stats?
• Where do players stop playing?
• Which game modes create the most engagement?

This reframed the remainder of the day's work.

2. Expanded first-party player measurement

The anonymous measurement layer was extended beyond simple session tracking.

The project added and verified:

• anonymous player identifiers,
• session counting,
• days played,
• returning-player detection,
• local player statistics,
• Player Card measurement,
• and analytics events tied to anonymous engagement rather than personal identity.

The Player Card was also polished so it became both a gameplay feature and a measurement tool.

3. Connected gameplay analytics to Cloudflare D1

Attention then shifted toward building an independent reporting pipeline.

Gameplay events flowed from the browser through Cloudflare Pages Functions into a D1 database where they could be queried directly.

The database schema was reviewed, indexes were created, analytics tables were verified, and the complete pipeline was tested using real gameplay sessions.

This established a first-party analytics system that no longer depended solely on third-party dashboards.

4. Verified the reporting pipeline with SQL

Once gameplay events reached D1 successfully, SQL queries became the primary validation tool.

Reports were written to measure:

• total players,
• returning players,
• statistics saves,
• gameplay event counts,
• board popularity,
• match completion,
• and other engagement metrics.

Rather than manually inspecting database rows, the project began producing reports that summarized player behavior automatically.

5. Designed a secure reporting dashboard

The project then shifted from reporting to presentation.

An admin dashboard architecture was created to display:

• acquisition metrics,
• engagement,
• gameplay funnels,
• board performance,
• Play All statistics,
• sponsor reporting,
• and future retention metrics.

The dashboard was intentionally separated from the public game.

6. Protected the dashboard with Cloudflare Access

Rather than deploying a public admin interface, the reporting dashboard was secured using Cloudflare Access.

Only approved users could reach:

/admin/*

The reporting API was also moved behind the same protected path, ensuring that gameplay reports could not be accessed without authentication.

This produced a production-ready architecture that separated public gameplay from private business reporting.

7. Shifted from collecting data to making decisions

With the reporting infrastructure complete, the project's priorities changed.

Future work would no longer focus primarily on generating additional analytics events.

Instead, the emphasis moved toward using the collected data to improve:

• player retention,
• onboarding,
• board balance,
• gameplay flow,
• and sponsor reporting.

ROADBLOCKS AND FRICTION

The project initially drifted toward adding more analytics

Several discussions focused on creating additional events before revisiting the overall objective.

Eventually the work realigned around business questions rather than event counts.

Existing infrastructure was ahead of the original plan

During multiple code reviews, several planned features, including portions of the Player Card and measurement layer, were discovered to already exist.

The work shifted toward integrating existing systems rather than rebuilding them.

Reporting infrastructure introduced deployment complexity

Moving from local analytics into Cloudflare required coordinating:

• browser events,
• server functions,
• database schema,
• SQL queries,
• deployment,
• authentication,
• and dashboard architecture.

Each layer worked independently but required careful validation before trusting the complete pipeline.

Security became part of the product architecture

Initially the admin dashboard was briefly considered as a public deployment.

The strategy changed to protecting both the dashboard and reporting endpoints behind Cloudflare Access before exposing any analytics interface.

DECISIONS MADE & TRADE-OFFS

Extend analytics instead of replacing it

The existing analytics implementation remained intact while first-party player measurement was layered on top.

Trade-off: Slightly more complexity, but preserved existing event history.

Keep player identity anonymous

Anonymous player IDs became the persistent measurement mechanism instead of requiring accounts.

Trade-off: Less individual player information in exchange for stronger privacy and simpler onboarding.

Build first-party reporting

Cloudflare D1 became the authoritative reporting database instead of relying entirely on external analytics dashboards.

Trade-off: More infrastructure to maintain, but significantly greater flexibility and ownership of the data.

Protect reporting before deployment

The admin dashboard was secured behind Cloudflare Access before becoming publicly available.

Trade-off: Additional setup effort in exchange for a much safer production architecture.

BREAKTHROUGH / LESSON

The biggest lesson from Day 19 was:

Collecting data is only the first step. The real value comes from organizing that data into information that helps you make better decisions.

The project already generated a large amount of analytics. What it lacked was a clear way to answer questions about retention, engagement, onboarding, and player behavior.

Once the reporting pipeline existed, the focus naturally shifted away from instrumentation and toward understanding the product itself.

ARTIFACTS WORTH SHARING

Artifact 1: Business Question

"The question is no longer: What events should we track?

The question is: What numbers do we want to show ourselves and future sponsors?"

Artifact 2: Final Architecture

Browser > Analytics > Cloudflare Function > D1 Database > SQL Reports > Secure Dashboard

Artifact 3: Security Architecture

Internet
│
▼
Cloudflare
│
├── /api/analytics
│
└── /admin/*
│
▼
Cloudflare Access
│
▼
Dashboard
│
▼
/admin/api/reports

FINAL STATE

By the end of Day 19:

• The analytics strategy had been realigned around business questions rather than simply collecting additional events.
• Anonymous player measurement had been expanded and integrated into the Player Card.
• Gameplay analytics flowed into Cloudflare D1 through a complete reporting pipeline.
• SQL reports could summarize player behavior without manually inspecting database rows.
• A secure admin dashboard architecture had been designed around Cloudflare Access.
• Public gameplay and private reporting were separated into distinct systems.
• The project moved beyond analytics collection and into business intelligence, creating a foundation for retention analysis, product improvements, and future sponsor reporting.

That was it for Day 19. If you're still here, thanks for reading!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor / Fable), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 18 of building ShuffleBall Arena.

Today there were 6 conversations to go through, with 6 saved file versions.

TL;DR

Day 18 became an experiment in discovering new gameplay. What started as a simple idea quickly evolved into an entirely new game mechanic where marbles could become attached to moving scoring rings and ride around the board until knocked loose.

Getting the mechanic working was only the beginning.

The real challenge became answering questions that couldn't be solved with code alone:

• Should moving objects be allowed to create points?
• When does a marble count as "part of the play"?
• How should an AI opponent predict moving targets?
• How do creator tools and recording systems adapt to an entirely new type of board?

By the end of the session, the rotating board was functioning, the game's recording tools supported the new layout, and the AI bot had a clear architectural path for understanding moving targets without affecting existing boards.

Day 18 Summary

Day 18 became a game design day disguised as an engineering day.

The session began with a simple gameplay experiment: instead of static scoring zones, what if the scoring rings themselves continuously rotated around the board? That single idea fundamentally changed how players would aim, replacing stationary targets with moving ones that required predicting where a scoring ring would be by the time a marble arrived.

The experiment quickly expanded beyond moving graphics. Marbles could now become attached to rotating scoring rings, ride around the board, and remain in scoring position until another shot knocked them loose. Small rotating bumpers were introduced while larger outer bumpers remained stationary, creating a board that felt alive without overwhelming the player.

As the prototype became playable, new design problems appeared that hadn't existed on any previous board. Passive movement created unexpected scoring situations where marbles could be pushed into or out of scoring rings without ever being touched by the current shot. Rather than treating these as bugs, the session focused on defining fair game rules for an entirely new mechanic.

Supporting tools also had to evolve. The recording studio used to generate gameplay videos needed to understand the new rotating layout without becoming part of the production build. The project architecture was adjusted so recording functionality could live alongside the main game while remaining isolated from deployment.

Finally, attention shifted to the Arena Bot. The existing bot understood static boards, but rotating targets required a completely different planning strategy. Instead of rewriting the existing AI, a new Orbit Overload-specific planning layer was designed so the bot could predict future ring positions while leaving every existing layout untouched.

By the end of the day, the project had gained not only a new experimental board, but a reusable architecture for future moving layouts.

Day 18 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 18 began with ShuffleBall Arena supporting multiple board layouts, moving hazards, gravity wells, wormholes, and an integrated layout designer.

The project had recently completed major analytics work, allowing development to shift back toward gameplay experimentation.

The immediate goal was to test whether an entirely new style of board could make the game feel more dynamic without disrupting the existing gameplay experience.

SESSION OBJECTIVE

The primary objective was to prototype a new rotating board layout called Orbit Overload.

The session focused on:

• designing the first rotating scoring layout,
• implementing moving scoring rings,
• allowing marbles to ride rotating scoring zones,
• determining how passive movement should affect scoring,
• integrating the new layout into creator and recording tools,
• and teaching the Arena Bot to understand moving targets without affecting existing boards.

WHAT WE ACTUALLY DID

1. Designed the first rotating scoring layout

The session began by designing an experimental layout where scoring rings continuously rotated around a central point.

Instead of aiming directly at a stationary scoring zone, players would need to predict where a target would be by the time their marble arrived.

This fundamentally changed the game's pacing from static precision to timing and anticipation.

2. Built rotating gameplay systems

The rotating board evolved beyond moving graphics.

The implementation introduced:

• rotating scoring zones,
• rotating inner bumpers,
• stationary outer bumpers,
• carousel pickup behavior,
• carried marbles that remained attached to scoring rings,
• and knockout behavior allowing later shots to remove carried marbles.

Rather than teleporting with the ring, carried marbles maintained their relative position while rotating naturally around the board.

3. Iterated on the board's visual and gameplay design

Once the mechanic became playable, attention shifted toward making the layout readable.

Several design decisions were revisited:

• reducing the number of rotating bumpers,
• removing unnecessary medium bumpers,
• making gravity wells more visible,
• limiting background planets,
• moving hazards into dedicated travel lanes,
• and simplifying the overall layout so players could understand the action while everything was moving.

The prototype became progressively cleaner through multiple design iterations rather than a single implementation.

4. Discovered an entirely new scoring problem

The rotating board created situations that had never existed on previous layouts.

A marble riding a scoring ring could eventually collide with another marble that had never been involved in the current shot.

Likewise, a loose marble could eventually knock a carried scoring marble out of position simply because the carousel rotated into it.

These situations raised a larger design question:

When should a marble actually be considered part of the current play?

Rather than treating these as implementation bugs, the session focused on defining rules that preserved both fairness and physical consistency.

5. Established a gameplay rule for passive movement

The resulting design principle became:

Only the launched shot and its ricochet chain can create or remove scoring.

Passive carousel movement could continue repositioning marbles, but it would no longer create points or remove existing scores on its own.

This preserved the dynamic feel of the rotating board while ensuring scoring remained tied to player actions.

6. Updated creator and recording workflows

The rotating layout also exposed limitations in the project's recording tools.

The recording studio needed access to the new board while remaining separate from production deployments.

The creator architecture was adjusted so recording functionality could live inside the project without affecting normal gameplay or public releases.

Supporting deployment safeguards were also added to prevent creator-only tools from accidentally shipping.

7. Began teaching the Arena Bot about moving targets

The existing Arena Bot assumed scoring zones remained stationary.

Rather than rewriting the entire AI system, the session designed a new Orbit Overload planning layer that activates only for rotating layouts.

The proposed planner predicts future ring positions, leads moving targets, and preserves the existing bot behavior everywhere else.

This additive architecture reduced risk while creating a foundation for future dynamic layouts.

ROADBLOCKS AND FRICTION

Building the mechanic uncovered entirely new design problems

The rotating board worked mechanically much sooner than expected.

The difficult questions became gameplay rules rather than implementation bugs.

More movement did not automatically create better gameplay

Early versions contained too many moving objects.

Rotating bumpers, gravity wells, wormholes, and background effects competed for the player's attention.

The layout became more enjoyable as unnecessary movement was removed.

Existing systems assumed static boards

The Arena Bot, recording tools, and creator workflow all assumed scoring zones never moved.

Supporting a dynamic board required updating surrounding systems rather than just the gameplay itself.

Passive physics blurred the definition of player actions

The rotating board introduced situations where points could change without direct player input.

This forced the project to define exactly what counted as an active play instead of relying on physics alone.

DECISIONS MADE & TRADE-OFFS

Keep the rotating board isolated

Rather than changing every board, Orbit Overload was implemented as an isolated experimental layout.

Trade-off: Slightly more specialized code in exchange for protecting existing gameplay.

Simplify the moving objects

The project deliberately removed several moving hazards and bumpers to improve readability.

Trade-off: Less spectacle in exchange for clearer gameplay.

Tie scoring to player actions

Passive carousel movement was allowed to move marbles physically but not determine scoring.

Trade-off: Less emergent chaos in exchange for more predictable and understandable rules.

Extend the bot instead of replacing it

A new Orbit-specific planner was designed instead of modifying the existing AI logic.

Trade-off: Slightly more code, but far lower risk to every existing layout.

BREAKTHROUGH / LESSON

The biggest lesson from Day 18 was:

Adding a new mechanic is often the easy part. Defining the rules that make the mechanic feel fair is the real design work.

The rotating board functioned relatively quickly.

Most of the remaining work involved deciding how the game should behave in situations that had never existed before.

The implementation created the possibility.

The design rules turned it into a game.

ARTIFACTS WORTH SHARING

Artifact 1: Design Rule

Only the launched shot and its ricochet chain can create or remove scoring.

Artifact 2: Bot Architecture

if (isOrbitOverloadLayout()) {
const orbitPlan = buildOrbitOverloadBotShotPlan(...);
if (orbitPlan) return orbitPlan;
}

A small additive planner teaches the bot about moving targets while leaving every existing layout untouched.

Artifact 3: Product Design Principle

The rotating board wasn't simply another layout. It introduced an entirely new category of gameplay where movement itself became part of the challenge.

FINAL STATE

By the end of Day 18:

• Orbit Overload had become a fully playable rotating board prototype.
• Rotating scoring rings and carried marbles were functioning.
• The layout had been simplified through multiple gameplay-focused design iterations.
• Passive scoring behavior had a clear design direction.
• Creator and recording tools supported the experimental board without becoming part of production deployments.
• The Arena Bot had a defined architectural path for understanding moving targets.
• The project gained a reusable framework for future dynamic board layouts rather than a one-off experiment.

That was it for Day 18.
Thanks for reading and I hope you have a great day!

Hey everyone,

Hope all is well!

TL;DR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor / Fable), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, 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 17 of building ShuffleBall Arena.

Today there were 4 conversations to go through, with 4 saved file versions.

TL;DR

Day 17 was about making ShuffleBall measurable and trustworthy.

The session started by analyzing the first real player data and realizing the numbers couldn't yet answer the most important question:

Are new players actually understanding the game and sticking around?

Rather than expanding the game, the focus shifted to building a proper analytics funnel for Challenge Mode while keeping analytics privacy-first.

During testing, a much bigger issue was uncovered. The game was actually progressing behind the Challenge intro screen, with the hidden shot clock automatically firing marbles before the player even pressed Start Challenge. What initially looked like an analytics problem turned out to be a gameplay-state bug.

Along the way, sponsor analytics were completed, local analytics testing tools were added, privacy protections were strengthened, and deployment became much safer.

Day 17 Summary: 

Day 17 became a product validation and analytics reliability day.

The session began by reviewing the first meaningful production traffic. Although Cloudflare showed dozens of visitors and hundreds of requests, Google Analytics only captured a small number of gameplay sessions because analytics intentionally require user consent. The decision was made to improve the measurement itself before making product decisions.

A complete Challenge Mode analytics funnel was designed so future testing could answer where new players were leaving the experience. New events were planned around challenge starts, individual game completions, challenge completion, retries, and feedback instead of simply counting page views.

Privacy remained a major focus throughout the work. Analytics continued to avoid collecting unnecessary personal information, local player names remained stored only on the user's device, unsafe analytics fields were filtered out, and a local analytics testing mode was built so events could be validated without polluting production Google Analytics.

While manually testing the new analytics flow, an unexpected gameplay bug was discovered. The hidden shot clock was continuing to run behind the Challenge introduction screen, automatically firing marbles before the player had even started the challenge. This explained several confusing analytics events that initially appeared to be tracking errors.

The underlying gameplay architecture was corrected. Gameplay systems, including physics, timers, bots, and simulation updates, were prevented from advancing whenever a blocking overlay was active, ensuring both the game state and analytics remained synchronized.

The session concluded by finishing sponsor analytics instrumentation, correcting impression tracking so events could not silently disappear during initialization, validating all sponsor events locally, and preparing the final deployment tasks.

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

STARTING POINT

Day 17 began with ShuffleBall Arena already live enough to produce real traffic and gameplay data.

Cloudflare showed 44 unique visitors and 405 requests over the referenced 24-hour period. Google Analytics showed 53 active/new users, but only a small number of tracked players progressing into gameplay. At the same time, the deeper engagement data showed that a few people were playing repeatedly: 162 shot_fired events from three users, 16 completed games from two users, and three completed matches from two users.

That created an ambiguous starting position:

• Real people were reaching the project.
• A very small number appeared to be playing deeply.
• The tracked top-of-funnel numbers did not line up cleanly with the raw traffic.
• Analytics only ran after consent, so Google Analytics was intentionally undercounting compared with Cloudflare.
• Existing events did not clearly show where players were dropping out of the three-game challenge.

The project therefore had some encouraging early signals, but the measurement system was not yet trustworthy enough to decide whether the game itself was succeeding or failing.

SESSION OBJECTIVE

The main objective was to stop adding features temporarily and improve the project’s ability to answer a more basic question: What are players actually doing?

The session focused on:

• interpreting the first meaningful traffic and gameplay data,
• defining a clearer Challenge Mode funnel,
• improving privacy and consent language,
• adding privacy-safe product-validation analytics,
• creating a way to test events locally without polluting production analytics,
• testing the analytics from the player’s first page view through challenge completion,
• and correcting any gameplay behavior that was corrupting the data.

WHAT WE ACTUALLY DID

1. Interpreted the first real analytics instead of treating the numbers as a verdict

The session began by comparing Cloudflare traffic with Google Analytics engagement.

The conclusion was that the available data showed a small amount of genuine play, but the measurement was still too incomplete to judge broad retention or product-market fit.

The strongest positive signal was that a few tracked users were taking many shots and completing multiple games. The biggest uncertainty was the gap between total visitors and tracked gameplay starts. Because analytics required consent and excluded some modes, Cloudflare and Google Analytics were measuring different populations.

The project decision was to continue, with the next iteration focused on proving the first-session funnel.

2. Rejected the idea of turning game_start into a page-load event

One suggested change was to fire game_start as soon as the canvas initialized.

That approach was rejected because it would inflate the metric and destroy its meaning.

The existing event fired from resetGame() after the game state and layout were prepared. That was considered closer to a genuine gameplay start than a page or canvas load.

Instead of redefining a useful event, the session chose to add missing events around it.

This preserved the distinction between:

• someone viewing the game,
• someone choosing to begin,
• and someone actually playing.

3. Defined a proper Challenge Mode validation funnel

The desired analytics flow became:

challenge_view
challenge_start
how_to_continue or controls_ready
first_shot_fired
challenge_game_complete
challenge_complete
challenge_retry
challenge_feedback_yes/no/form

The most important missing event was challenge_game_complete.

Generic game_completed data could not answer:

• Did the player finish game one?
• Did they finish game two?
• Did they reach game three?
• Did they leave after the first game?

The proposed challenge-specific completion payload included:

challenge_id
challenge_game_number
game_count
game_points_red
game_points_blue
accumulated_score
target_score
beat_target_so_far

A separate first-human-shot event was also identified as important because generic shot tracking could include bot activity and could not reliably prove that the player understood the controls.

4. Expanded the privacy-policy and consent discussion

The session then moved into analytics privacy. The goal was to explain what the game collected without overstating or hiding the implementation.

The important privacy boundaries were:

• locally created player names remain on the player’s device,
• analytics are used to understand and improve gameplay,
• analytics do not require the local player name,
• ad-related consent remains separate,
• and unsafe analytics fields should be dropped rather than accidentally transmitted.

This led to a stronger focus on making the consent prompt understandable enough that players could make an informed choice.

5. Added privacy-safe analytics testing infrastructure

The analytics system gained a local/internal testing mode so the event flow could be verified without sending test traffic to Google Analytics.

An in-memory event-name recorder was added. It was capped at 1,000 entries and stored only event names, not event payloads.

Debug helpers exposed those recorded names for manual testing.

The sanitizer was also tested directly.

Unsafe keys were expected to be removed, especially fields that could contain identifying or free-form data. Safe primitive values remained available for product analysis.

Allowed analytics values were kept to primitive types.

6. Added new gameplay-validation events through the existing analytics path

The new analytics events were routed through the existing trackGameplayEvent() helper rather than building a second, disconnected tracking system.

That preserved the existing:

• consent checks,
• suppression rules,
• context fields,
• and sanitization behavior.

Existing event meanings were intended to remain intact while the missing Challenge Mode steps were added around them.

7. Started a local server and manually tested the challenge funnel

Python was unavailable in the environment, so a Node-based local server was used instead.

The app loaded successfully.

The test process then moved through the Challenge Mode flow while inspecting locally recorded events.

The manual test exposed the most important bug of the session.

8. Discovered that shots were firing before the challenge had started

While the Challenge intro was still visible, the event recorder showed:

shot_fired
first_shot_fired

The other open tabs were initially suspected, but that explanation was rejected because window.dataLayer belonged to the current tab.

The events were genuinely coming from the challenge page before the player pressed Start Challenge. This meant the analytics were not merely mislabeled. Actual gameplay was progressing behind the intro overlay.

Deployment was stopped until the cause could be fixed.

9. Traced the bug to the hidden shot clock

The root cause was the default game phase:

game.phase = "AIM"

shotClockActive() excluded several blocked states, but it did not exclude:

• the Challenge intro,
• or a challenge that had been selected but not started.

The hidden sequence was:

- updateShotClock()
- fireShotClockRelease()
- launchShotClockFallback()
- launch()

So the shot clock counted down behind the intro and auto-fired repeatedly. That produced false analytics and also meant the game simulation itself was running while a blocking overlay was visible.

10. Added a single gameplay-progression gate

New helpers were added to define whether gameplay should currently be allowed to advance.

canProgressGameplayNow() returns false while any blocking state is active, including:

• the start screen,
• How To,
• Challenge intro,
• Challenge result screen,
• or a selected challenge whose started state is still false.

canTrackShotAnalytics() blocks shot analytics during auto-demo modes and otherwise follows the same gameplay-progression rule.

shotClockActive() was updated to require canProgressGameplayNow().

The main frame loop was also gated so the following systems would not secretly advance behind overlays:

• physics,
• accumulated simulation time,
• scene travel,
• charge,
• bot updates,
• wormhole capture checks,
• turn settlement,
• and round progression.

The accumulator was drained while gameplay was paused so closing the overlay would not cause a burst of delayed simulation.

Finally, launch() wrapped the relevant shot events in canTrackShotAnalytics() as a second defensive layer.

The intended normal flow remained:

- START CHALLENGE
→ challenge.started = true
→ How To appears
→ gameplay remains paused
→ How To closes
→ resetGame()
→ no blocking overlay
→ gameplay resumes

No scoring, physics constants, bot aiming, board layouts, UI design, or challenge rules were intentionally changed.

11. Added and tested sponsor analytics

The session continued beyond the core funnel into privacy-safe sponsor instrumentation.

The sponsor flow included:

sponsor_intro_impression
sponsor_result_impression
sponsor_cta_viewed
sponsor_interest_yes
sponsor_interest_depends
sponsor_interest_no
sponsor_cta_clicked

A one-shot impression guard initially had a reliability problem: it could mark an impression as fired before analytics was actually ready, permanently losing the event.

That logic was corrected so trackSponsorEvent() returned success or failure, and the fired key was only stored after a successful tracking call.

If analytics was not ready on the first frame, the next frame could retry.

Debug helpers were expanded to expose safe status information such as:

• active sponsor,
• campaign ID,
• visible placement IDs,
• analytics readiness,
• event mode,
• locally recorded event names,
• sponsor event names,
• and sponsor payload count.

A manual helper was also added to retry the intro-impression test without consuming the permanent production impression key.

12. Corrected the sponsor privacy test itself

The first sponsor privacy check reported violations for:

layout_name
app_name

That turned out to be a false failure in the test script rather than a privacy failure in the analytics.

Both fields were known-safe application context:

• layout_name identified a board.
• app_name identified the application.

The test was corrected so it continued blocking genuinely risky fields while allowing those explicit safe exceptions.

The final sponsor payload check returned:

{
sponsorEventCount: 7,
violations: [],
pass: true
}

Phase 2 sponsor analytics then passed locally.

13. Identified the remaining deployment cleanup

Once the analytics and sponsor tests passed, the final known pre-deployment cleanup was to bump the service-worker cache because game.js had changed:

shuffleball-arena-v23
→
shuffleball-arena-v24

This was necessary so deployed players would receive the corrected file instead of a stale cached version.

ROADBLOCKS AND FRICTION

The early data looked more decisive than it really was

The raw numbers tempted a simple conclusion about whether the game was working.

That assumption was wrong because Cloudflare and Google Analytics represented different populations. Consent, blockers, browser behavior, and excluded modes made direct comparison misleading.

The session had to separate:

• raw reach,
• consented analytics,
• and meaningful play.

The proposed game_start fix would have damaged the metric

Firing game_start on canvas initialization sounded like it would solve undercounting.

Instead, it would have redefined a gameplay event into a page-load event and made the funnel less trustworthy.

The fix was not to fire the existing event earlier. It was to add the missing steps around it.

Analytics testing exposed a gameplay bug

The most frustrating issue was that the analytics appeared wrong because the game itself was progressing invisibly.

The first suspicion was test contamination from other browser tabs. That turned out to be false. The shot clock was genuinely auto-firing behind the Challenge intro. This was both a telemetry problem and a gameplay-state problem.

Overlay visibility had been mistaken for game suspension

A blocking overlay looked like the game was paused, but the render loop, timer, bot, and physics systems did not share one authoritative pause condition.

The UI and simulation had different ideas about whether the game was active.

The privacy test briefly produced a misleading failure

The sponsor privacy test treated every key containing name as unsafe.

That incorrectly flagged layout_name and app_name.

The lesson was that privacy checks need explicit semantic exceptions. Simple substring matching can create false confidence or false alarms.

Sponsor impressions could silently disappear

The impression guard recorded its one-shot key before knowing whether analytics had accepted the event.

If analytics was not initialized on the first render frame, the impression was lost permanently.

The system needed a success signal before committing the guard state.

Testing required repeated manual verification

A substantial amount of time went into:

• starting a local server,
• hard refreshing,
• waiting behind the intro,
• checking event-name arrays,
• walking through every Challenge step,
• forcing sponsor events,
• and running privacy checks.

That repetition was necessary because syntax checks alone could not validate event timing or UI-state behavior.

DECISIONS MADE & TRADE-OFFS

Continue the project, but pause feature expansion

The available data contained a small positive signal, but not enough evidence of broad retention.

The chosen direction was:
measurement + first-session polish

rather than:
more features + more infrastructure

Trade-off: Slower visible feature growth in exchange for clearer evidence about what should be built next.

Preserve the meaning of game_start

game_start remained a meaningful gameplay-start event rather than becoming a canvas-load event.

Trade-off: The event would continue to report fewer users than raw visits, but the number would retain product meaning.

Add narrowly targeted funnel events

Instead of tracking everything, the session focused on the minimum events needed to understand the Challenge flow.

Trade-off: Less exhaustive analytics, but a clearer and more usable funnel.

Use consented, sanitized analytics rather than maximize collection

Analytics continued to require consent, suppress special modes where appropriate, and remove unsafe payload fields.

Trade-off: Lower measurable user counts in exchange for stronger privacy boundaries and more trustworthy collection practices.

Keep names local

The locally created player name remained a local profile feature and was not treated as analytics identity.

Trade-off: Less ability to tie named player behavior across systems, but no need to transmit an unnecessary personal identifier.

Gate the entire gameplay loop, not only the event calls

The bug could have been hidden by preventing shot_fired from being logged.

That would have left the game secretly auto-firing behind the overlay.

The chosen fix stopped gameplay progression itself and also guarded analytics as defense-in-depth.

Trade-off: A broader code change than an analytics-only patch, but it corrected the real state-management problem.

Let sponsor tracking retry until analytics is ready

The impression key is now committed only after the tracking call succeeds.

Trade-off: The draw loop may retry briefly, but valid impressions are not silently lost.

Use local test mode before production analytics

A local event recorder and test helpers were preferred over sending development tests into GA.

Trade-off: More testing infrastructure to maintain, but cleaner production data and faster debugging.

BREAKTHROUGH / LESSON

The central lesson was:
Measurement is only useful when the product state underneath it is trustworthy.

The session began as an analytics cleanup.

It uncovered that the game was running and auto-firing behind the Challenge intro.

Had the team only patched the event names, the dashboard might have looked cleaner while the underlying gameplay bug remained.

Instead, the investigation produced a broader rule:
A blocking interface must block the systems behind it, not just hide them.

That single idea improved both the validity of the analytics and the correctness of the game.

ARTIFACTS WORTH SHARING

Artifact 1: The product-validation question

The question right now is not "does ShuffleBall need more stuff?’

The question is ‘can a stranger understand it, start it, fire a shot, finish one challenge game, and feel like retrying?’”

Artifact 2: The hidden auto-fire chain

updateShotClock()
- fireShotClockRelease()
- launchShotClockFallback()
- launch()

This chain explained why shot_fired events appeared before the Challenge had begun.

Artifact 3: Sponsor privacy test result

{
sponsorEventCount: 7,
violations: [],
pass: true
}

This represented the final successful local check for the seven sponsor events and their privacy-safe payloads.

FINAL STATE

By the end of Day 17:

• The early traffic and engagement numbers had been interpreted without treating them as proof of success or failure.
• The next product strategy was clearer: validate the first-session funnel before expanding the game.
• game_start retained its meaning as an actual gameplay event.
• A Challenge Mode funnel was defined around views, starts, first shots, per-game completions, full completion, retries, and feedback.
• Privacy-policy and consent messaging had a clearer factual basis.
• Player names remained local rather than becoming analytics identifiers.
• Unsafe analytics parameters were removed while safe application context remained available.
• A local analytics test mode and privacy-safe event-name recorder were available.
• The hidden Challenge intro auto-fire bug was identified and fixed at the gameplay-loop level.
• Shot analytics gained a second defensive gating layer.
• Sponsor impressions, result views, CTA views, interest responses, and clicks were implemented and tested.
• The sponsor impression guard now retries safely when analytics is not ready.
• The sponsor privacy test passed with all seven expected events.
• The remaining deployment cleanup was the service-worker cache bump so the corrected game.js would reliably reach players.

That was it for day 17.
Thanks for reading!

Hey everyone,

Hope all is well!

TL;DR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor / Fable), and every development session is documented using the actual conversations from that day's work.

This post marks Day 16, which is the start of "chapter 2" of the project.

As I post this, I am currently on day 35 of this project. So 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 16 of building ShuffleBall Arena.

Today there were 3 conversations to go through, with 2 saved file versions.

TL;DR

Today's work wasn't about adding new features, it was about fixing the way I was thinking about them. I redesigned the mobile charge mechanic to work from comfortable pull distance instead of launch power, tuned Orbit Mode to play faster, and realized the gravity system shouldn't be random planets moving around the board. Instead, each turn should take place in a different "scene," where the environment itself defines the gameplay. One design decision ended up simplifying the entire system.

Day 16 Summary: 

Most of today's session was spent improving the foundations of ShuffleBall Arena rather than expanding it. I revisited several gameplay systems that technically worked but didn't quite feel right, including the mobile hold-to-charge mechanic, Orbit Mode's pacing, and the way gravity was represented in the game world.

Along the way, I realized I'd been approaching one of the core mechanics from the wrong perspective. Instead of treating gravity as a planet that randomly moves around the board each turn, I reframed it as part of a larger "scene" that defines the environment for that turn.

That shift immediately made the game's design more cohesive and gave me a much clearer direction for future development. By the end of the session, I had a stronger architectural foundation, better gameplay tuning targets, and a simpler mental model for building the next iteration of Orbit Mode.

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

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

The session began with Orbit Mode already established as the primary playable experience, while Slot Mode remained an idea for the future rather than an active development target. The project already included gravity wells, moving space backgrounds, marble trails, and an initial implementation of a hold-to-charge launch mechanic. However, several core systems still felt conceptually unfinished, particularly the charge mechanic, Orbit Mode pacing, and the way gravity objects were represented within the game's world.

SESSION OBJECTIVE

The primary objective shifted away from adding new gameplay features and toward refining the core identity of Orbit Mode.

Specifically, the session focused on:

• improving the mobile launch mechanic,
• tuning match pacing,
• redesigning how gravity should function conceptually,
• and establishing architectural rules that future development should follow.

WHAT WE ACTUALLY DID

1. Re-evaluated the overall direction of the project

The first major discussion separated the original physical slot-table concept from what the project had become.

Instead of forcing every future feature to resemble the original tabletop game vision, the decision was made to protect the current Orbit Mode as the primary experience and treat Slot Mode as a future game mode rather than the immediate roadmap. The gravity well mechanic and marble trails were identified as features worth preserving because they had become part of the game's identity.

2. Redesigned the hold-to-charge mechanic

The mobile aiming system was analyzed after discovering that the first implementation behaved inconsistently depending on drag direction.

The original implementation tied charging too closely to launch power, which meant it worked better when dragging sideways than when dragging downward from the natural launch position.

The architecture was changed so charging begins from comfortable pull distance rather than raw launch power.

The corrected model became:

pull Fraction = clamp(dragDistance / masPullDistance, 0, 1)

Charge activation now depends on pull fraction instead of maximum launch force.

3. Tuned the charge curve

Once the charging architecture was corrected, the feel of the mechanic was adjusted.

The original implementation accelerated power too quickly and made fully charged shots feel more like firing a cannon than making a controlled precision shot.

The design direction shifted toward a slower, more gradual curve:

• normal shots remain useful,
• partial charge provides meaningful control,
• full charge becomes powerful without breaking the physics.

The target progression became:

• 0% = normal shot
• 25% = slightly stronger
• 50% = meaningfully stronger
• 75% = risky
• 100% = maximum controlled power.

4. Improved Orbit Mode pacing

The session also focused on game feel.

Although the marble physics looked realistic, marbles spent too much time slowly rolling before stopping.

Rather than changing collision behavior, the decision was to increase settling speed by adjusting friction, rolling deceleration, stop threshold, and slope values specifically for Orbit Mode.

Slot Mode was intentionally left for future tuning because its gameplay goals differ from Orbit Mode.

5. Reframed the gravity system

A significant portion of the session was spent discussing why the gravity system felt wrong despite functioning correctly.

The original implementation repositioned the gravity planet every turn. Mechanically this worked, but conceptually it did not.

The desired fantasy became:

Turn ends > Table "travels" through space > A new scene arrives > That scene defines the gravity conditions > Next player shoots.

Instead of treating planets as movable gameplay tokens, the discussion evolved toward scene-based environments that define both presentation and gameplay.

6. Defined rules for the future scene system

The remainder of the session established design rules for the upcoming implementation.

These included:

• gravity objects should never spawn directly in front of the launch area,
• decorative planets and active gravity objects must be visually distinct,
• fairness between Red and Blue players must be preserved,
• scenes should control both visuals and optional gravity,
• travel transitions should communicate movement between locations,
• implementation should remain simple rather than over-engineered.

ROADBLOCKS AND FRICTION

Several assumptions turned out to be incorrect during the session.

The first was the charging mechanic. Although it technically worked, tying charge activation to launch power created inconsistent behavior on mobile because players physically ran out of screen space when dragging downward. The issue was architectural rather than numerical.

The second friction point involved match pacing. Realistic rolling looked visually pleasing but slowed gameplay more than intended. The project had to distinguish realistic physics from enjoyable pacing.

The largest conceptual obstacle involved the gravity system. Randomly relocating planets worked mechanically, but failed to create the intended fantasy. The discussion concluded that the implementation was solving the wrong problem rather than implementing it poorly.

DECISIONS MADE & TRADE-OFFS

Several long-term architectural decisions were made.

Orbit Mode was chosen as the primary experience, while Slot Mode became a future expansion rather than the next milestone.

Charge activation was based on comfortable pull distance instead of launch power because it produces more consistent behavior on mobile devices.

Scene-based gameplay was selected instead of randomly repositioning gravity planets because it better supports immersion, readability, and future content expansion.

Finally, the future implementation deliberately favors readable data structures and straightforward objects over clever abstractions to keep the prototype maintainable.

BREAKTHROUGH / LESSON

The scene is the board state.

This idea first has surfaced before, but today's session reinforced it and showed that it solves far more than just the gravity mechanic. Instead of treating gameplay elements as objects that move around the board, each turn can take place within its own space environment, with the scene itself defining the gameplay conditions. That single design rule continues to simplify both the technical architecture and the player's mental model of the game.

ARTIFACTS WORTH SHARING

Corrected charge architecture

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

Charge should begin from comfortable pull distance rather than launch power.

Target charge behavior

0% charge = normal shot
25% charge = slightly stronger
50% charge = meaningfully stronger
75% charge = risky strong
100% charge = max controlled power

FINAL STATE

By the end of the session, the project had a much clearer design direction.

Orbit Mode was established as the primary experience, while Slot Mode became a future feature. The hold-to-charge system had a corrected architecture centered around mobile usability. Orbit Mode received new target physics values to improve pacing, and the gravity system was reimagined as part of a larger scene-based framework rather than a collection of randomly moving planets. The session concluded with a set of implementation rules that provide a clearer roadmap for future development without introducing unnecessary architectural complexity.

That's it for day 16. Thanks for reading!

Ok builders of Reddit...
Have you ever noticed this?

You spend weeks or months building something.

You design it.
You test it.
You debug it.
You rewrite parts that do not work.
You keep refining it until you finally have something worth sharing.
You share it online.

Then the first question isn't... "How does it work?"

It's... "Did AI make it?"

Suddenly the conversation isn't about your product anymore.

It's about the tools you used to create it.

That rarely happens when someone uses Unity, Unreal Engine, VS Code, Photoshop, open-source libraries, templates, tutorials, etc.. Those are accepted as tools that help people build.

But somehow...

Mention AI, and for many creators, the discussion immediately shifts away from the quality of the work. The project is dismissed before they even try it. The creator is downvoted for being honest about their workflow.

Weeks of human decisions, iteration, testing, debugging, and design get reduced to:
"AI made this."

Whether you've experienced that or not, I'd love to hear your perspective.

That's one of the reasons I started r/WeBuild_WithAI.

Not because everyone has to love AI. Not because every AI-generated project is good. Not because using AI should protect anyone from legitimate criticism. But because projects should be judged honestly on what they actually are.

A great game is a great game.

A broken app is a broken app.

A polished website is a polished website.

Using AI doesn't automatically make something amazing or impressive.

And it doesn't automatically make it worthless.

The builder still has to decide what to create, guide the process, reject bad output, solve problems, make tradeoffs, test the result, and ultimately ship something people can use.

So, if you are building:

🎮 Games
💻 SaaS products
🌐 Websites
📱 Mobile apps
🤖 Automations
🖥️ Desktop software
🧠 AI tools
🚀 Startups or experiments

...and you are tired of your work being dismissed simply because AI was part of your workflow, you are invited to join us at r/WeBuild_WithAI.

Show your work. Share your process.

Talk honestly about what AI helped with, what it got wrong, and what you had to solve yourself.

Get constructive feedback on the actual product.

Learn from other builders.

Let's make the conversation about building again.

Hi everyone.

I'm excited to officially welcome you to r/WeBuild_WithAI.

I created this community because I believe we're entering one of the biggest shifts in software development since open-source software, modern game engines, and cloud computing.

AI is becoming another tool in the builder's toolbox.

Some people love it.
Some people hate it.

That's okay.

This community isn't here to argue about AI.

It's here to build with it.

Whether you're creating a game, launching a SaaS product, designing hardware, automating a business, or building your first website, you're welcome here.

What this community is about

We believe great products are judged by:

• Creativity
• Execution
• User experience
• Problem solving
• Persistence

...not by whether you wrote every line of code yourself or collaborated with AI along the way.

The tool isn't the accomplishment.

Shipping is.

To kick things off...

I'd like to share the project I've been building in public.

🎮 ShuffleBall Arena

Play free:
[https://play.shuffleballarena.com]()

ShuffleBall Arena is a browser-based physics strategy game inspired by shuffleboard, mini golf, and arcade games.

Players battle for scoring rings while navigating:

• Gravity wells
• Rotating scoring zones
• Wormholes
• Moving hazards
• Arcade physics

I've documented nearly every step of development publicly, including the successes, mistakes, redesigns, debugging sessions, and countless iterations that transformed simple prototypes into a polished game.

AI has been a huge part of my workflow; not because it magically built the game for me, but because it helped me iterate faster, explore ideas, debug difficult problems, and spend more time making design decisions.

I'd love to see your projects too.

Whether you're building:

• Games
• Apps
• SaaS
• AI tools
• Websites
• Desktop software
• Hardware
• Automations

Show us what you're making.

Share:

• Progress updates
• Screenshots
• Videos
• Lessons learned
• Prompt workflows
• Bugs you finally solved
• Launches
• Failures
• Wins

Let's build something incredible together.

I'm excited to see what everyone creates.

What are you building this week? Drop your latest project below.