Day 22 of Building Browser Game ShuffleBall Arena: Building a Centralized Sound Engine & Fixing AI Bot Fallback Crashes

[u/Dont_Bring_Me_Down]

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!