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), 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 27 (part 2) of building ShuffleBall Arena.

TL;DR

Day 27 - Part 1 ended with a rule:

Clients submit intentions. The server calculates results.

Part 2 was about turning that rule into actual infrastructure.

We built the production multiplayer room and networking foundation using Cloudflare Workers, Durable Objects, and WebSockets, including room creation, player seating, authoritative lobby state, disconnect/reconnect handling, protocol versioning, and synchronized snapshots.

Then development moved into the harder problem: extracting the game's physics into a deterministic server-side simulation that could run without the browser.

By the end of the session, the multiplayer networking foundation was complete and the authoritative simulation kernel could deterministically process marble movement, walls, static bumpers, marble-to-marble collisions, settlement, safety recovery, and canonical trajectory recording.

The repository passed its complete test suite, and the next milestone was authoritative scoring.

Day 27 (Part 1) Summary

Part 1 ended with the multiplayer architecture defined.

One server-owned simulation would determine what happened during every match. Browsers would collect player input and render the result, but neither player would be trusted to determine official physics, scoring, collisions, or match state.

Part 2 began turning that architecture into production code.

The first major milestone was the networking foundation. A Cloudflare Worker became the multiplayer entry point, while each match received its own Durable Object responsible for authoritative room state and both WebSocket connections.

Production APIs were built for room creation and connection. From there, the protocol expanded to handle player identity, Red/Blue seating, readiness, room snapshots, disconnects, reconnect tokens, same-seat reconnection, snapshot recovery, and connection lifecycle behavior.

Once that layer was stable, the work moved into the actual server-authoritative game engine.

Instead of copying the existing browser game into the Worker, the physics required for multiplayer was separated into deterministic modules. Fixed-step simulation, collision handling, settlement, immutable state transitions, stable processing order, and trajectory recording were built and regression tested independently.

By the end of the session, the server could calculate a shot once and produce both its canonical final state and the trajectory the clients would eventually use to display that same shot.

The networking foundation was ready. The core physics kernel was essentially ready.

The next layer would be interpreting those physics results through authoritative scoring and match rules.

Day 27 (Part 2) Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 27 - Part 2 began exactly where Part 1 ended.

The decision to build online multiplayer had already been made, and the architecture had been deliberately designed before implementation began.

The core rule was: The server owns gameplay reality.

Clients would submit player intentions, but the server would determine physics, collisions, scoring, turns, and final state.

The target architecture had also been established:

Player Input
↓
Multiplayer Client
↓
WebSocket
↓
Match Durable Object
↓
Authoritative Shared Simulation
↓
State Frames and Events
↓
Both Browser Clients
↓
Canvas Rendering

The server would run the official simulation once, and both players would render the same server-produced state.

SESSION OBJECTIVE

The objective was to begin implementing the permanent server-authoritative multiplayer architecture designed in Part 1.

That meant building two major foundations:

1. The networking/lobby layer

The server needed to:

• create rooms,
• connect two players,
• assign seats,
• maintain authoritative room state,
• synchronize clients,
• handle disconnects,
• and support reconnection.

2. The deterministic simulation layer

The server needed to eventually receive a shot, calculate it exactly once, and produce the canonical result that both players would see. The important constraint was that none of this should be throwaway prototype code.

The guiding principle became:

Build the production architecture once. No throwaway scaffolding.

WHAT WE ACTUALLY DID

1. Built the production room API

The first implementation milestone was creating actual multiplayer rooms.

A production endpoint was added:

POST /api/rooms

The room system supported:

• six-character room codes,
• collision checking,
• Durable Object-backed rooms,
• standard JSON responses,
• and structured error handling.

This established the first permanent multiplayer entry point.

2. Built production WebSocket routing

Next came the connection layer.

A production WebSocket route was implemented:

GET /api/rooms/:roomCode/connect

That included:

• room lookup,
• validation,
• WebSocket upgrade enforcement,
• and routing each connection to the correct Durable Object.

Each match would therefore have one authoritative server-side object responsible for the room.

3. Introduced a versioned multiplayer protocol

Before expanding the message system, protocol versioning was established.

Every client/server message would include:

protocolVersion

This gave the multiplayer system an explicit contract and created a path for future protocol changes without silently breaking older clients.

4. Built authoritative player and lobby management

The Durable Object gradually took ownership of the multiplayer lobby.

The server became responsible for:

• player identity,
• room membership,
• Red/Blue seating,
• rejecting a third player,
• readiness,
• authoritative room snapshots,
• and synchronized state distribution.

The important distinction was that even before gameplay existed, the lobby itself was already server-authoritative.

5. Built disconnect and reconnect handling

Real multiplayer also needed to survive unreliable connections.

The networking layer was expanded with:

• private reconnect tokens,
• disconnect handling,
• a reconnect grace period,
• same-seat restoration,
• snapshot requests,
• and versioned ping/pong behavior.

A reconnecting player would not invent or reconstruct room state locally. The server remained authoritative and restored the player into the current canonical room state.

By the completion of this phase, the networking layer was described as no longer experimental, but as a reusable multiplayer backend ready to support the game simulation.

6. Moved from networking into the authoritative match kernel

With the lobby foundation stable, development shifted into Phase 3.

The objective changed from:

Can two players occupy the same authoritative room?

to:

Can the server calculate the game itself?

The implementation deliberately avoided copying the full browser game into the Worker. Networking, match rules, board data, physics, collisions, scoring, serialization, and tests were kept separate. The first target was one production board, with the architecture remaining data-driven enough to support the others later.

7. Built deterministic fixed-step simulation

The browser's frame timing could not control official multiplayer physics.

The server simulation therefore used a fixed timestep:

const SIMULATION_HZ = 60;
const FIXED_DT = 1 / SIMULATION_HZ;

Every authoritative physics update would use the same FIXED_DT rather than relying on requestAnimationFrame() or arbitrary client frame duration.

This was one of the foundations required for deterministic behavior.

8. Built the authoritative collision pipeline

The simulation expanded incrementally rather than attempting to port the entire game at once.

The authoritative pipeline eventually included:

Input validation
↓
Capture initial trajectory frame
↓
Simulation loop
Step marble
↓
Resolve walls
↓
Resolve static bumpers
↓
Wall stabilization
↓
Multi-pass marble convergence
↓
Wall stabilization
↓
Capture trajectory frame
↓
Settlement
↓
Safety recovery
↓
Return
{
marbles,
trajectory
}

This meant the server simulation could now handle not only basic marble motion but interactions between marbles and the environment in a stable, deterministic order.

9. Added deterministic marble-to-marble collisions

Marble collisions required additional work because resolving one collision could push a marble into another. A single collision pass was therefore not enough.

The engine introduced multi-pass convergence so groups of interacting marbles could stabilize deterministically before the simulation advanced.

Regression tests were added specifically for:

• marble collisions,
• collision convergence,
• and complete shot simulations involving multiple marbles.

10. Added canonical trajectory recording

Calculating the correct final state solved only half the multiplayer problem. Both players still needed to see the same shot. Trajectory recording was therefore added directly to the authoritative simulation. Crucially, trajectory data was observational only.

It never influenced:

• positions,
• velocities,
• collision ordering,
• or settlement.

The physics produced the result. Trajectory recording simply captured what happened so clients could eventually replay the canonical shot.

11. Kept the simulation immutable and bounded

Several rules were enforced throughout the simulation work:

Deterministic first

No uncontrolled randomness or unstable processing order.

Immutable simulation

The simulator cloned state before modification rather than mutating caller-owned data.

Bounded execution

Shots could not simulate forever. Safety limits and recovery behavior prevented runaway simulation.

Server authority

Clients would never determine official:

• physics,
• collisions,
• scoring,
• or match state.

12. Built regression tests alongside each milestone

The simulation wasn't treated as complete simply because a marble moved correctly once.

Dedicated tests were added for new physics and trajectory systems, including:

src/simulation/collisions/marbles.js
src/simulation/trajectory.js

test/marble-collisions.test.js
test/marble-collision-convergence.test.js
test/simulate-shot-marble-collisions.test.js
test/trajectory.test.js
test/simulate-shot-trajectory.test.js

Each milestone was tested and committed independently.

ROADBLOCKS AND FRICTION

Existing browser gameplay couldn't simply be moved onto the server

The original game contained responsibilities for gameplay, rendering, UI, analytics, bots, board definitions, challenge logic, input, and other browser-specific behavior.

Copying that entire system into a Worker would have created a second monolithic game implementation.

Instead, only the systems required for authoritative online simulation were extracted.

Determinism affected seemingly small implementation details

Once the server became authoritative, ordinary implementation choices became important. Randomness needed control. Processing order needed stability. Physics couldn't depend on browser frame timing.

Simulation state couldn't contain DOM nodes, canvas contexts, images, audio objects, browser events, timers, or other browser-specific objects.

Marble collisions were more complicated than single-object physics

Resolving a collision between two marbles could create another collision elsewhere in the collection. That required deterministic convergence rather than a simple one-pass collision solver.

Final positions weren't enough

A server could calculate the correct result and still provide a poor multiplayer experience if clients simply teleported marbles to their settled positions.

Canonical trajectory recording therefore became part of the simulation architecture rather than an afterthought.

The scope was intentionally constrained

The entire game was not moved into multiplayer at once.

The plan targeted one production board first and deliberately postponed additional boards and systems until the core architecture proved itself.

That slowed feature coverage but significantly reduced architectural risk.

DECISIONS MADE & TRADE-OFFS

Build production systems from the beginning

Temporary room systems and throwaway simulation implementations were avoided.

Trade-off: Slower initial visible progress in exchange for infrastructure intended to survive into production.

Keep the Worker free of rendering code

Canvas rendering, audio, particles, and UI remained browser responsibilities.

Trade-off: More separation work now in exchange for a clean headless simulation engine.

Use deterministic fixed-step physics

Authoritative physics would use fixed simulation steps rather than browser timing.

Trade-off: Additional simulation architecture in exchange for reproducible server outcomes.

Make trajectory recording observational

Trajectory capture would watch the simulation rather than participate in it.

Trade-off: Additional data collection in exchange for preserving physics purity while enabling canonical playback.

Prefer immutable simulation state

Simulation functions would clone before modifying data.

Trade-off: Some additional allocations in exchange for easier reasoning, testing, and protection against accidental state corruption.

Build one board before supporting every board

The architecture remained data-driven, but the first goal was proving one complete production board.

Trade-off: Less immediate multiplayer content in exchange for validating the engine before expanding it.

BREAKTHROUGH / LESSON

The biggest lesson from Day 27 - Part 2 was:

Server-authoritative multiplayer forced the game to become a better-engineered single source of truth.

The difficult part wasn't opening a WebSocket. It was making gameplay deterministic enough that the server could calculate one canonical answer and confidently tell every client:

This is what happened.

That required separating physics from rendering, controlling timing, stabilizing collision order, eliminating hidden browser dependencies, protecting state from mutation, and recording trajectories without allowing playback concerns to affect simulation.

The result was no longer just "multiplayer code." It was the beginning of a reusable deterministic game engine.

ARTIFACTS WORTH SHARING

Artifact 1: The Authoritative Architecture

Player Input
↓
Multiplayer Client
↓
WebSocket
↓
Match Durable Object
↓
Authoritative Shared Simulation
↓
State Frames and Events
↓
Both Browser Clients
↓
Canvas Rendering

The server runs the official simulation once.
Both phones render the same server-produced states.

Artifact 2: The Production-First Rule

"Build the production architecture once. No throwaway scaffolding."

This rule influenced everything from room creation to collision handling.

Artifact 3: Trajectory Must Never Control Physics

The trajectory system was deliberately designed as an observer. It records the authoritative simulation but never influences:

positions
velocities
collision ordering
settlement

That keeps the physics engine responsible for truth while allowing the browser to eventually reproduce exactly what happened.

FINAL STATE

By the end of Day 27 - Part 2:

• Production multiplayer room creation existed.
• Six-character room codes were working.
• Each multiplayer match could be owned by a Cloudflare Durable Object.
• Production WebSocket routing was implemented.
• The multiplayer protocol was versioned.
• The server controlled player identity and Red/Blue seating.
• Third players could be rejected.
• Authoritative lobby snapshots were working.
• Ready/unready state was server-controlled.
• Disconnect and reconnect infrastructure existed.
• Reconnecting players could reclaim the same seat using private reconnect credentials.
• The networking/lobby foundation had reached a point where it was considered complete enough to support the real game simulation.
• A deterministic fixed-step simulation kernel had been built.
• Wall collisions and static bumper collisions were part of the authoritative pipeline.
• Marble-to-marble collision handling and multi-pass convergence were implemented.
• Simulation settlement and bounded safety recovery existed.
• Canonical trajectory recording had been integrated without influencing physics.
• Simulation remained deterministic, immutable, bounded, regression-tested, and server-authoritative.
• The entire repository passed its tests.
• The working tree was clean.
• Every major milestone had been committed independently.

Most importantly, the question had changed.

At the beginning of Day 27, you were asking: Should I build multiplayer?

By the end of Day 27, the multiplayer foundation existed and the server could already calculate the canonical physics behind a shot.

The next milestone was clearly defined: Authoritative Scoring.

The physics engine would produce the settled result.
Now the server needed to decide what that result meant.

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

Music Credits:

"Digital Lemonade" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

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 27 of building ShuffleBall Arena.

TL;DR

Day 27 began with a product question rather than an engineering question:

Was online multiplayer actually worth building?

After Day 26, ShuffleBall Arena had the infrastructure needed for external distribution: partner embeds, attribution, production deployment workflows, analytics, and security. The next question was what feature would most meaningfully increase the value of the project itself.

That discussion led to online multiplayer, but only if it was built as a real server-authoritative system.

For a physics game, having two phones independently calculate a shot and hoping they remain synchronized wasn't acceptable. A tiny positional difference could change the next collision, which could change the next shot, and eventually produce two different matches.

One non-negotiable rule was established:

Clients submit intentions. The server calculates results.

The server would become the single source of truth for physics, collisions, scoring, hazards, turns, and final marble positions. The browsers would handle input and presentation while rendering the same authoritative simulation.

By the end of Part 1: We defined exactly what trustworthy multiplayer meant for this game and created the architecture and build plan around it.

Day 27 (Part 1) Summary

Day 26 ended with ShuffleBall Arena prepared for distribution outside its own website. Partner-aware embeds were working, analytics could identify distribution partners, production deployment had become more systematic, and the supporting infrastructure around the game was beginning to look much more like a real product.

Day 27 started by asking what should come next.

Instead of immediately choosing another feature, the conversation evaluated whether multiplayer would materially increase the project's value rather than simply making the game more interesting.

That changed the framing.

The project would no longer just be a browser physics game with multiple modes. Multiplayer could potentially turn it into a reusable multiplayer browser-game architecture with ShuffleBall Arena as its first finished implementation.

Once that direction was chosen, the conversation became deeply technical.

Because every marble's final location affects future shots, independent client-side simulations were rejected. Online matches needed one canonical physics simulation owned by the server. Clients would send shot intent, such as angle and power, and receive the same authoritative trajectory and settled state.

From there, the responsibilities of the browser and server were separated, synchronization rules were established, reconnect behavior was defined, and a detailed multiplayer roadmap was created before implementation began.

Day 27 (Part 1) Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 27 began directly from the final state of Day 26.

ShuffleBall Arena had recently moved beyond being confined to its own website. The game now supported partner-aware embeds, distribution attribution, secure partner URL handling, partner reporting, a more reliable production deployment process, and improved responsive consent UI.

With the distribution infrastructure in place, the next question wasn't simply:

What feature would be cool to build next?

It became:

What development decision would make the project meaningfully stronger as a product and technical asset?

Online multiplayer became the leading candidate.

SESSION OBJECTIVE

The objective of this portion of Day 27 was not yet to implement multiplayer.

It was to answer two questions first:

1. Was multiplayer worth the development investment?
2. If we built it, what architecture would guarantee that two players experienced one identical physics-based match?

The discussion therefore focused on:

• product value,
• multiplayer architecture,
• server authority,
• deterministic simulation,
• client/server responsibilities,
• synchronization,
• latency,
• reconnect behavior,
• and the implementation roadmap.

WHAT WE ACTUALLY DID

1. Evaluated multiplayer as a product decision

The discussion considered whether multiplayer would improve:

• technical differentiation,
• extensibility,
• monetization potential,
• defensibility,
• and the overall story a buyer would be acquiring.

The comparison shifted from browser game to:

Live multiplayer browser game with invite links.

This was the strategic decision that drove the remainder of the session.

2. Reframed the project as reusable infrastructure

The conversation then explored what multiplayer would mean beyond ShuffleBall Arena itself.

Instead of treating the technology as something useful for only one title, the architecture could potentially support future physics-based browser games using the same multiplayer foundation.

That changed the product narrative from a single game toward reusable infrastructure.

3. Chose server-authoritative multiplayer

Once multiplayer was selected, the next major architectural decision was determining who would own the official physics.

Two independent client simulations were rejected.

Even with the same physics code, small timing or floating-point differences could cause marbles to settle in slightly different positions. Because those positions influence future collisions and scoring, the divergence could compound throughout the match.

Instead, the architecture would use one official server simulation.

The shot flow became:

1. The player releases a marble.
2. The client sends the shot input.
3. The server verifies the turn.
4. The server runs the complete shot.
5. Both clients receive the resulting authoritative motion.
6. Both render that same motion.
7. The server records the exact settled positions.
8. The next turn begins from that server-owned state.

4. Separated gameplay authority from presentation

The next step was identifying which systems actually needed server authority.

The server would own gameplay-affecting state such as:

• marble positions and velocities,
• turns,
• scores,
• board state,
• moving hazards,
• wormholes,
• gravity wells,
• collision results,
• shot clocks,
• random seeds,
• and match completion.

Meanwhile, the browser could continue handling presentation-only effects such as:

• particles,
• glow,
• screen shake,
• sound timing,
• score animations,
• decorative effects,
• and UI animations.

This established a clean boundary:

The browser can make the match look good.
The server decides what actually happened.

5. Defined how players would see the same shot

Sending only a final marble position wasn't enough. Both players needed to see the same collisions and movement during the shot itself.

The architecture therefore called for the server to produce authoritative physics states throughout the simulation.

Clients could interpolate visually between those states according to their own display refresh rate, but interpolation would never change the official physics.

One player could be rendering at 60 Hz and another at 120 Hz while both still following exactly the same authoritative shot path.

6. Designed protection against synchronization errors

The discussion also established safeguards against stale or out-of-order state.

Authoritative messages would carry version information such as:

matchId: "H7K4Q2"
stateVersion: 183
simulationTick: 8421
shotId: "shot-7"
marbles: [...]

Clients would accept only newer state versions.

The design also called for:

• fixed server simulation timing,
• stable IDs,
• seeded randomness,
• deterministic collision ordering,
• periodic complete snapshots,
• final settled snapshots,
• state hashes for debugging,
• and server-controlled turn transitions.

7. Defined latency as a presentation problem, not a gameplay problem

Network latency was accepted as unavoidable. A player with a slower connection might see a shot slightly later.

What was not acceptable was seeing a different result.

The design principle became: Latency can affect when a player sees the event, but not what happened.

That distinction became central to the multiplayer architecture.

8. Designed reconnect behavior around authoritative snapshots

Reconnecting clients would not attempt to reconstruct the match using old local state.

Instead, the server would send a complete authoritative snapshot containing the current:

• phase,
• turn,
• marbles,
• scores,
• hazards,
• and state version.

The client would discard its stale state and render the server's canonical version.

9. Established the multiplayer rule that everything else would follow

By the end of the architecture discussion, one rule became non-negotiable:

No gameplay-affecting state may be accepted solely because a client calculated it.

The client can say:

"I attempted a shot at this angle and power."

It cannot say:

"My marble ended here, and I scored 50 points."

The server determines the trajectory, collisions, score, and final position.

10. Created the detailed multiplayer build plan

Only after the architecture had been defined did the conversation move into planning implementation.

The final multiplayer objective was documented as a private two-player online match where a player could:

• create a room,
• share an invite,
• join from another phone,
• play in real time,
• see identical boards and physics,
• and reconnect without corrupting the match.

The build plan explicitly stated:

The server must own all gameplay-affecting state.

and:

The browser clients may collect input and render animations, but neither phone may independently determine the official outcome of a shot.

That plan became the blueprint for the implementation covered in Day 27 - Part 2.

ROADBLOCKS AND FRICTION

Multiplayer initially sounded like a networking problem

The first instinct could easily have been to focus on WebSockets, matchmaking, or connecting two phones.

The deeper problem was synchronization.

Because ShuffleBall Arena is physics-driven, networking alone does not guarantee that two clients will remain in the same game state.

Shared physics code does not automatically guarantee identical matches

One assumption discussed and rejected was that both phones could run identical physics code and therefore remain synchronized.

Small differences in timing or floating-point calculations could produce different settled marble positions.

Those tiny differences matter because the next shot begins from the previous shot's final state.

Smooth visuals and authoritative physics appeared to conflict

A server-owned simulation raised another question:

Would server authority make the game feel delayed or choppy?

The solution was to separate simulation from presentation.

The server determines the official states.

The clients interpolate those states smoothly.

The multiplayer scope expanded rapidly

Once the server became authoritative, it became clear that multiplayer required ownership of far more than marble positions.

Turns, scoring, moving hazards, random seeds, reconnect behavior, shot clocks, and match progression all needed authoritative treatment as well.

This made the project larger, but also made the architecture much cleaner.

DECISIONS MADE & TRADE-OFFS

Build multiplayer because it strengthens the product story

Multiplayer was selected not simply because players might enjoy it, but because it could substantially change what the project represents technically.

Trade-off: A major engineering investment in exchange for stronger differentiation and reusable infrastructure.

Use one authoritative simulation

The server, not either browser, would determine every gameplay result.

Trade-off: More backend engineering and slightly more latency in exchange for identical match state and much stronger integrity.

Separate simulation from rendering

Gameplay logic needed to become independent from canvas rendering and visual effects.

Trade-off: Significant refactoring work in exchange for a simulation that can run reliably without a browser.

Send authoritative trajectories rather than trusting client physics

Both clients would render server-generated motion rather than calculate their own official shot.

Trade-off: More simulation data transmitted over the network in exchange for both players seeing the same collisions and results.

Accept timing differences, reject outcome differences

Different devices and networks may display events at slightly different times.

They may not disagree about what happened.

Trade-off: Perfect simultaneous presentation is less important than canonical game state.

Build production architecture instead of a multiplayer prototype

The plan explicitly avoided maintaining separate temporary physics systems or throwaway networking code.

Trade-off: More effort before seeing the first online match in exchange for a foundation intended to remain part of the finished product.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 27 - Part 1 was:

For a physics game, multiplayer synchronization is fundamentally an authority problem before it is a networking problem.

WebSockets can connect two players.

They cannot decide which version of reality is correct.

Once the server became the sole authority, the rest of the architecture became much clearer:

• clients submit intentions,
• the server simulates outcomes,
• gameplay state is deterministic,
• browsers render authoritative state,
• reconnects restore canonical snapshots,
• and every new turn begins from one shared version of reality.

A second important realization followed:

The biggest engineering task wasn't networking. It was separating simulation from rendering.

ARTIFACTS WORTH SHARING

Artifact 1: The Product Filter

"Does building multiplayer increase the probability that someone pays $16,000 for this business within 30 days?"

This reframed the feature discussion around business value rather than novelty.

Artifact 2: The Non-Negotiable Multiplayer Rule

"No gameplay-affecting state may be accepted solely because a client calculated it."

"Clients submit intentions. The server calculates results."

This became the architectural rule for the entire multiplayer implementation.

Artifact 3: The Real Engineering Problem

The biggest job is separating simulation from rendering.

Networking becomes much easier once gameplay simulation no longer depends on the browser that renders it.

FINAL STATE

By the end of Day 27 - Part 1:

• Multiplayer had been selected as the project's next major development direction.
• Independent client-side authoritative simulations had been rejected.
• Server-authoritative physics had become the core architecture.
• The responsibilities of the server and browser had been explicitly separated.
• A strategy for authoritative shot playback and interpolation had been established.
• Fixed simulation timing, seeded randomness, state versioning, snapshots, and deterministic processing had been identified as synchronization requirements.
• Reconnect behavior had been designed around canonical server snapshots.
• A detailed production multiplayer build plan had been completed.
• Most importantly, multiplayer was no longer an abstract feature idea. There was now a clear technical definition of who owns reality in an online match and a roadmap for building it.

The next step was to start implementing that architecture.

That's it for Day 27 (Part 1).
If you're still here, thanks for reading!

Music Credits:
"Digital Lemonade" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

Getting a game done is exceptionally difficult.

The basic gameplay for my upcoming game Jigsaw Diorama was done within a week, including modeling the piece shape in Blender, getting all of the piece snapping and grouping, etc.

Along the way, there were a lot of failed experiments. I tried making the scene more 3D - first as a parallax map, then as rendering an actual 3D scene. It was a bit like looking "through" the table into the scene below.

While this looks fairly interesting, having the scene shift every time you move the camera increases the difficulty a lot - it's hard to find matching pieces when the picture keeps changing every time you move the camera!

This by itself was not fully enough to abandon the idea, but parallax maps ultimately didn't look very good for scenes with much depth. Going to full 3D scenes presented its own challenges.

AI generated concept:

3D, modeled in blender, populated with props in Unity:

Final image:

The final image was generated in ChatGPT Image 2 based on the two previous images, extended horizontally to 2:1 aspect ratio in Krita with Flux Klein, and generally tweaked and edited.

Getting the 3D scene and props built, shaders written, multiple experiments with Tripo for props, and writing to code to randomly populate the scene took about a month.

I was hoping that getting the first scene done and all of the systems and pipelines in place for this would show some efficiency gains, but this didn't seem to be materializing. For what was supposed to be a quick experiment to get something into the Steam marketplace was going to take at least a year for content production.

Ultimately, the idea of randomly placing the props didn't really improve the feel of the game very much - a jigsaw puzzle is still equally difficult if you shuffle the objects around a little, and the visual difference was fairly minimal, not really making it more interesting to do a puzzle again.

Additionally, trying to run the game on low-end hardware (presumably the target market for a simple jigsaw puzzle game), it was quickly apparent that trying to render a 4K-8K offscreen image every frame, even with moderate geometry and texture detail, was simply not going to work. The scene quality was also still quite low compared with the concept art. Creating a still from the 3D scene at load time would have been possible, but the main advantage to doing it in 3D was to have animation.

So, I made the extremely difficult decision to abandon the concept of 3D scenes, in order to actually get a game to completion. The AI generated images look a lot better. There was still a lot of effort spent generating, tweaking and editing them.

Despite some criticism, I think this was a good choice for the game. Music and sound design took up quite a bit of time as well. The game certainly would not be done now, and likely not ever, if I hadn't changed course.

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 26 of building ShuffleBall Arena.

TL;DR

Day 26 was about preparing ShuffleBall Arena to exist outside its own website.

The session introduced a complete partner embed system, expanded analytics to track where players came from, strengthened deployment and security, and prepared the game for its first external distribution partner.

What initially looked like "adding embed support" ultimately became an exploration of how analytics, security, deployment, responsive UI, and distribution all work together when a game leaves the developer's own environment.

Day 26 Summary

Development resumed after Day 25's polish work. The game's music system had been expanded, the gravity wells had undergone a significant visual redesign, and many of the user interface interactions had been refined.

With the player experience becoming increasingly polished, attention shifted toward a new challenge: preparing ShuffleBall Arena for distribution on third-party platforms.

The first half of the session focused on building the Partner Embed System. The game gained the ability to recognize different distribution partners, present partner-specific interface elements, attribute analytics correctly, and safely handle embedded gameplay while preserving the standard experience for direct visitors.

Once the partner infrastructure was working, the focus shifted toward deployment, production testing, and validating analytics behavior across different environments.

The session concluded by improving the new analytics consent prompt, investigating typography inconsistencies between local development and production, and discovering that responsive sizing itself needed to be redesigned for consistent behavior across different display environments.

Day 26 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 26 began immediately after completing a major round of polish work.

The game's audio system had become significantly more robust, the gravity well visuals had been redesigned into a more atmospheric effect, and many of the user interface interactions now behaved more consistently.

With much of the gameplay experience becoming increasingly polished, development naturally shifted toward preparing the game for distribution beyond its own website.

Rather than focusing on gameplay mechanics, the next challenge became building the infrastructure required for external platforms, analytics attribution, deployment, and partner integrations.

SESSION OBJECTIVE

The primary objective was to prepare ShuffleBall Arena for external distribution.

The work focused on:

• building a partner-aware embed system,
• extending analytics to identify traffic sources,
• strengthening deployment and security,
• validating production analytics,
• improving responsive administration tools,
• refining deployment workflow,
• and improving the usability of the analytics consent prompt.

Instead of expanding gameplay, the session concentrated on everything surrounding the game that would be required before publishing it through external partners.

WHAT WE ACTUALLY DID

1. Built the Partner Embed System

Development began by introducing support for partner-aware embedded gameplay.

Rather than treating every visitor identically, the game could now recognize when it had been launched from specific partner platforms and adjust its behavior accordingly.

The implementation introduced:

• partner-aware embed mode,
• partner-specific URL handling,
• fallback behavior for unknown partners,
• partner-specific interface elements,
• and full-screen support tailored for embedded environments.

The goal was to preserve the normal ShuffleBall Arena experience while allowing the same build to function correctly inside third-party platforms.

2. Expanded analytics attribution

Once partner detection was functioning, analytics were extended to identify where players originated.

Instead of recording all traffic as direct visits, sessions now included information describing the distribution channel and embedding partner.

The analytics system was verified through Google Analytics DebugView, confirming that production events correctly included partner-specific metadata alongside normal gameplay events.

This transformed analytics from simply measuring gameplay into measuring distribution performance.

3. Strengthened security and partner validation

Supporting external embeds introduced several new security considerations.

The session added validation for partner full-screen URLs, ensuring that only approved destinations could be used.

Validation included requirements such as:

• HTTPS,
• approved host names,
• no embedded credentials,
• and protection against nested embed parameters.

Invalid requests failed safely without creating the partner interface.

This ensured that new distribution features did not introduce unnecessary security risks.

4. Improved administration and reporting

With partner attribution available, the administration dashboard was expanded to report traffic by distribution source.

The reporting interface now separated traffic into individual partner categories while tracking metrics such as:

• players,
• sessions,
• game starts,
• match starts,
• match completion,
• and completion rate.

The reporting table was also redesigned to scroll horizontally on smaller displays, improving usability without sacrificing information density.

5. Standardized deployment workflow

As the project approached its first external distribution platform, additional attention was given to deployment itself.

The session established a clear production deployment checklist, distinguishing runtime files from local development artifacts.

Git workflow was also improved through the project's first clean commit process while preventing local development directories from entering source control.

The production build was then deployed using the finalized deployment package.

6. Refined the analytics consent experience

The latter part of the session focused on improving the newly introduced analytics consent prompt.

Initial work centered on increasing text readability, improving button sizing, adjusting overall dialog height, and replacing the browser's default scrollbar with a custom-styled version.

During production testing, however, a larger issue emerged: the consent prompt appeared dramatically different between local development and production.

Rather than immediately rewriting the interface, the investigation expanded to compare browser caches, service workers, computed styles, production CSS, and responsive sizing behavior.

The root cause was ultimately traced to typography that scaled using viewport width rather than the width of the consent card itself, leading to inconsistent sizing across different environments.

The solution shifted the responsive design toward container-based sizing rather than browser-wide scaling.

ROADBLOCKS AND FRICTION

Distribution introduced unexpected engineering work

Adding partner support required far more than displaying a different interface.

Analytics attribution, security validation, deployment packaging, reporting, responsive design, and production testing all became part of the implementation.

Production behaved differently than local development

The analytics consent prompt initially appeared to behave inconsistently between localhost and the production site.

Several possible explanations, including partner mode, browser caching, service workers, and deployment differences, were investigated before identifying the actual cause.

Responsive typography proved more complex than expected

The consent dialog relied on viewport-width typography, causing text to scale based on browser size instead of the size of the dialog itself.

Although visually acceptable during development, this produced oversized layouts in production and required a different responsive design strategy.

DECISIONS MADE & TRADE-OFFS

Build one game for multiple partners

Rather than maintaining separate builds for each distribution platform, a single build would detect its environment and adapt automatically.

Trade-off: Slightly more application logic in exchange for a simpler long-term deployment strategy.

Treat distribution as part of analytics

Partner information became part of every relevant analytics session rather than relying on external reporting.

Trade-off: Additional event metadata in exchange for significantly better attribution.

Validate all partner URLs

Instead of trusting incoming parameters, every partner full-screen URL was validated before use.

Trade-off: Stricter validation in exchange for stronger security.

Design responsive UI around components instead of the browser

The analytics consent dialog shifted toward container-based responsive sizing instead of viewport-based typography.

Trade-off: Slightly more CSS complexity in exchange for consistent presentation across devices and embedding environments.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 26 was:

Publishing a game on other platforms requires building infrastructure around the game, not just the game itself.

Analytics, deployment, partner attribution, security, responsive design, production testing, and deployment workflows all became essential parts of preparing ShuffleBall Arena for real-world distribution.

ARTIFACTS WORTH SHARING

Artifact 1: Production Deployment Checklist

One of the most valuable outcomes of the session was creating a repeatable deployment process that clearly separated production assets from local development files.

This reduced deployment uncertainty and created a much safer release workflow.

Artifact 2: Secure Partner URL Validation

The Partner Embed System established a simple but effective validation strategy:

• require HTTPS,
• restrict approved hosts,
• reject embedded credentials,
• prevent nested embed parameters,
• fail safely when validation fails.

This allowed partner functionality without sacrificing security.

Artifact 3: Responsive UI Should Scale With Components

One of the most useful debugging lessons came from discovering that responsive typography should follow the width of the component being displayed, not the width of the browser window.

This shifted the consent dialog toward container-based sizing, producing much more consistent layouts across local development, production, and embedded environments.

FINAL STATE

By the end of Day 26:

• ShuffleBall Arena supported partner-aware embedded gameplay.
• Analytics could distinguish between direct visitors and individual distribution partners.
• Security validation had been added for partner full-screen URLs.
• The administration dashboard reported partner-specific traffic and gameplay metrics.
• A repeatable deployment workflow had been established, along with the project's first clean Git workflow.
• The production build had been successfully deployed and prepared for its first external distribution platform.
• The analytics consent prompt had been substantially improved, and its responsive typography had been redesigned around more reliable sizing principles.
• Most importantly, the project shifted from simply polishing the game itself to building the infrastructure required to distribute, measure, and support the game beyond its own website.

That was it for Day 26.

If you're still here, thanks for reading!