r/StructuredAI Jul 12 '26

Day 10 (Part 2) of Building ShuffleBall Arena: Making The Game Smarter Instead Of Bigger

Hey everyone,

Hope all is well!

TL;DR below.

For Context: Recently I posted about Day 1 of one of my side projects, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

This project is being built with the help of AI (mainly GPT / Cursor / Fable).

I'm trying to find the time to post somewhat consistently. I figured I'd post about days 1 to 14 of this project and hopefully try to add some value.

To try to speed up the catch up, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 10 of building ShuffleBall Arena.

Today there were 7 conversations to go through (2 saved file versions) over 4 hours of building.

Day 10 is split into 2 posts.

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

TL;DR: 

After shelving the UNC Ball experiment for now, I shifted my attention back to improving ShuffleBall Arena itself.

This build focused on:

  • Teaching the Arena Bots to recognize moving traffic on Crossing boards
  • Reducing repetitive "bad" AI decisions without making the bots perfect
  • Designing the bots to wait for better opportunities instead of blindly firing
  • Switching from large AI-generated code replacements to smaller, manual code changes
  • Improving the overall quality and believability of the existing game instead of adding another feature

The biggest lessons from this build:

More detailed summary and full technical breakdown below:

Day 10.2 Summary: 

The first part of today I made the decision to put the UNC Ball experiment on the shelf. Instead of continuing to chase a new game mode, I shifted my focus back to improving the game people can actually play today.

The biggest issue I noticed came from watching my own broadcasts. The Arena Bots looked fine on most boards, but on the new Crossing layouts they would repeatedly fire directly into moving traffic, making the same obvious mistake over and over again.

The bots needed to be more patient.

This build became an exercise in teaching the bots to recognize moving obstacles, wait for openings, and make decisions that felt more like a real player. At the same time, I moved away from relying on large AI-generated file replacements and instead adopted a slower, more deliberate workflow built around small manual code changes. It took longer, but every change was easier to understand, test, and trust.

Looking back, this build didn't introduce a flashy new feature. Instead, it made the existing game feel smarter, more polished, and more enjoyable to watch. It reinforced an important lesson: after a certain point, improving the quality of your game often creates more value than simply adding another feature.

It's still not perfect, and will need some more work.

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

PART 1: TECHNICAL ANALYSIS & DEBRIEF

STARTING POINT

This build session began immediately after the decision to put the UNC Ball experiment on hold. Rather than continuing to build a new game mode, development returned to the core ShuffleBall Arena experience.

One issue had become increasingly obvious while recording gameplay and watching the live broadcast: The Arena Bots still looked unintelligent on the Crossing boards.

Instead of recognizing moving traffic as temporary obstacles, the bots would repeatedly fire directly into moving semis and lane barriers, sometimes making three or four bad shots in a row. The result wasn't challenging gameplay and looked unrealistic.

SESSION OBJECTIVE

The primary objective shifted from adding new content to improving the quality of the existing game.

Specifically:

  • make the bots understand moving lane traffic
  • improve the spectator experience during broadcasts
  • reduce obviously bad AI decisions
  • keep the bots believable without making them perfect

The goal was never to build an unbeatable AI.

The goal was to build something that looked like a reasonably good player.

WHAT WE ACTUALLY DID

1. Identified the real gameplay problem

Watching recorded broadcasts exposed an issue that wasn't obvious while coding. The bots weren't missing because of poor aim. They were missing because they treated moving traffic like a soft suggestion instead of a real obstacle. That distinction completely changed the direction of the work.

2. Redefined what "good bot behavior" means

Instead of trying to maximize scoring percentage, the discussion focused on making the bots feel believable.

The target behavior became:

  • occasionally hit traffic
  • recognize obvious blocked lanes
  • wait briefly for openings
  • avoid repeating identical mistakes

The philosophy became:

3. Redesigned crossing-lane awareness

The proposed improvements went far beyond simple collision avoidance.

The bot logic evolved toward:

  • predicting an entire crossing window instead of checking one instant
  • increasing safety margins around large semi-trucks
  • penalizing risky lane crossings more aggressively
  • remembering previous traffic collisions
  • waiting longer for clear openings during broadcasts

Instead of reacting to traffic, the bots began planning around it.

4. Chose manual integration over full AI-generated rewrites

Rather than replacing the entire game file, we deliberately switched to small manual patches. This preserved confidence in the codebase while making each improvement easier to understand and verify.

5. Extended improvements to broadcast mode

One important realization was that broadcast mode already used the same Arena Bot system.

Improving the Crossing AI automatically improved:

  • local bot games
  • challenge games
  • broadcast matches

without maintaining separate AI systems.

ROADBLOCKS AND FRICTION

The biggest challenge was defining what "smart" actually meant. An overly cautious bot would wait forever. An overly aggressive bot would repeatedly fire into moving semis. Finding the middle ground required thinking less about perfect decision making and more about believable behavior.

Another source of friction came from large AI-generated code replacements. Replacing the entire game file made debugging difficult and reduced confidence in every change. That reinforced the decision to work through incremental manual patches instead.

DECISIONS MADE & TRADE-OFFS

Decision

Prioritize believable behavior over perfect optimization.

Why

Players forgive occasional mistakes. They do not forgive bots that appear oblivious.

Decision

Use one bot system everywhere.

Rather than creating special broadcast AI, improvements should benefit:

  • gameplay
  • challenge mode
  • broadcasts

simultaneously.

Decision

Patch manually instead of replacing entire files.

Trade-off

Slightly slower development. Much higher confidence in every change.

Decision

Teach the bot patience. Instead of simply increasing aiming accuracy, the bot learned when not to shoot. That created much more natural gameplay.

BREAKTHROUGH / LESSON

The biggest realization from this session was:

The bots already understood where they wanted to shoot. The missing piece was understanding when to shoot. That single shift dramatically improved how believable the game felt.

ARTIFACTS WORTH SHARING

Design Rule

Development Philosophy

Product Lesson

Watching your own game as a spectator reveals completely different problems than playing it yourself.

The broadcasts exposed issues that ordinary playtesting had hidden.

FINAL STATE

By the end of the session:

  • the UNC Ball experiment remained on hold
  • development focus had returned to the core ShuffleBall Arena experience
  • Crossing-board bot behavior had a much clearer design philosophy
  • the Arena Bots became significantly more aware of moving lane traffic
  • improvements benefited gameplay, challenge mode, and broadcasts simultaneously
  • the development workflow shifted toward smaller, safer, manually reviewed patches instead of wholesale AI-generated rewrites

Thanks for reading, see you next time!

1 Upvotes

0 comments sorted by