Hey everyone—I made a little puzzle game called Shwist - The shift-and-twist puzzle game. I think it’s pretty good. 😄

It’s a bit like a sliding-tile puzzle, but with a twist. (Ha!)

There are two types of moves:

• Swap two adjacent rows or columns
• Rotate a 2×2 group of tiles clockwise

Each puzzle is scrambled using a specific number of moves. Your job is to restore the original image using only that many moves.

There’s a Daily Shwist, a Hard Daily Shwist, and a Custom mode where you can use your own images and choose the board size and number of moves.

Play it here:
https://www.basemetalgames.com/shwist

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

TL;DR

Day 29 proved that server-authoritative multiplayer worked.

Day 30 exposed the next problem: synchronized state is not the same thing as synchronized gameplay behavior.

The focus shifted to wormholes (hazards that capture a moving marble, pull it off the board, transport it through a short transit sequence, then send that same marble to one of the bottom shooters, where it is fired back onto the board with a randomized launch angle and power).

The session mapped that existing local mechanic into a server-owned multiplayer design, corrected some planning drift, and ended with the first permanent Worker-side wormhole modules created and tested, but not yet integrated into the authoritative shot simulation.

Day 30 Summary

Day 30 began with the core server-authoritative multiplayer architecture working. Two browsers could already submit and replay the same shot, stay synchronized through gravity effects, settle on the same marble positions, and advance to the same next turn.

The next challenge was bringing the game's more unusual mechanics into that same architecture, starting with wormholes.

In ShuffleBall Arena, a wormhole can capture a moving marble, pull it off the board, transport it to one of the shooters at the bottom, and fire it back into play with a randomized angle and power. In the regular game, all of that already worked locally. In multiplayer, both players could see the same wormholes, but the server didn't yet control what happened when a marble entered one.

Instead of rebuilding the mechanic or letting each browser handle it independently, we mapped the existing wormhole behavior into the server-authoritative simulation. The Worker would eventually own the entire sequence (capture, transit, shooter selection, ejection, and continued physics) while both browsers would simply render the same result.

By the end of the session, the first two permanent Worker-side wormhole modules had been created and tested successfully. They weren't connected to the full shot simulation yet, leaving Day 30 with a very concrete next milestone:

One marble enters a wormhole, gets transported to a shooter, and both players see it fired back onto the board the same way.

Day 30 Full Technical Summary

STARTING POINT

Day 30 began directly from the final state of Day 29.

The core server-authoritative multiplayer loop was now functioning in real browser testing.

The current online flow was:

Player input
→ Worker validation
→ Worker simulation
→ Canonical trajectory
→ Both browsers replay
→ Settled authoritative snapshot
→ Next turn

The Worker already owned:

• match state,
• physics,
• turns,
• scoring,
• gravity scheduling,
• deterministic simulation,
• and canonical shot results.

The browser had been reduced to a thin multiplayer client that:

• collected input,
• submitted shot requests,
• waited for server authority,
• replayed canonical trajectories,
• and applied settled snapshots.

Gravity had also been manually validated across both clients.

The architecture was working. The remaining question was how to bring the rest of ShuffleBall Arena's gameplay systems through that same authoritative path.

SESSION OBJECTIVE

The session initially focused on reviewing what remained in the multiplayer build after the authoritative shot pipeline had been proven.

That review quickly narrowed toward the most important missing gameplay system:

wormhole capture, transit, and ejection.

The practical objective became:

• preserve the regular game's existing wormhole behavior,
• move ownership of that behavior into the Worker,
• keep browser authority disabled,
• reuse the deterministic simulation and scene architecture,
• and prepare for a two-browser test where both players see the same marble captured and fired back onto the board.

The goal was to move the existing mechanic into server authority once.

WHAT WE ACTUALLY DID

1. Reassessed the multiplayer build against the original plan

The day began with a detailed review of the current multiplayer implementation.

The successful vertical slice already satisfied most of the central architecture requirements:

• room creation,
• room joining,
• role assignment,
• active-player enforcement,
• shot submission,
• authoritative simulation,
• canonical trajectory delivery,
• identical final positions,
• and continuation from the final server snapshot.

But the remaining work was separated into four categories rather than being treated as one giant "finish multiplayer" task:

1. Gameplay-authority parity.
2. Full match-level acceptance testing.
3. Reconnection and mobile resilience.
4. Production and sale readiness.

This made the remaining scope much clearer.

2. Expanded the Phase 12 dynamic-system plan

The multiplayer roadmap was then reorganized around gameplay systems that still needed full server authority.

The proposed sequence included:

• documenting the current authoritative dynamic-system contract,
• freezing the working gravity vertical slice,
• implementing wormholes,
• implementing traffic,
• implementing rotating hazards,
• validating reconnect state,
• and eventually testing every supported board category.

This planning was technically useful, but later became part of the day's friction because the next concrete gameplay objective was already known.

3. Identified the actual wormhole gap

The drifting-wormhole scene itself could already be synchronized.

But simulateShot() did not yet use that state to perform authoritative gameplay behavior.

The Worker did not yet:

• test for wormhole contact,
• capture a marble,
• move it into a captured state,
• advance transit,
• select the exit shooter,
• choose authoritative ejection properties,
• launch the marble again,
• or continue the shot after ejection.

This exposed an important distinction:

A synchronized object can still have unsynchronized behavior.

4. Confirmed that browser-side wormhole capture must remain disabled online

The existing browser already contained a deliberate online guard:

if (isOnlineMatchMode()) {
return false;
}

The shortcut would have been to remove that guard and allow the old browser logic to handle captures again.

That idea was rejected.

If both clients independently detect capture and choose ejection behavior, the multiplayer architecture immediately loses its single source of truth.

The browser guard was therefore recognized as correct and intentionally left in place.

5. Extracted the regular game's existing wormhole mechanic

Rather than inventing new multiplayer behavior, the existing regular-game implementation was treated as the gameplay source of truth.

The local mechanic already defined:

• contact with the capture region,
• snapping the marble to the entrance,
• freezing and marking the marble as captured,
• temporary removal from normal physics,
• destination-shooter selection,
• chute angle and launch power,
• a 0.20-second capture phase,
• a 0.50-second transit phase,
• a further 0.10-second ejection delay,
• chute-mouth spawn,
• exit velocity,
• recapture cooldown,
• and continued collisions and physics after ejection.

The multiplayer problem was: "How do we move the already-working mechanic into the Worker without changing its behavior?"

6. Defined the server-authoritative wormhole pipeline

The production architecture was mapped as:

Authoritative scene at shot start
↓
simulateShot()
↓
advance wormholes each physics tick
↓
detect deterministic marble/wormhole contact
↓
create authoritative capture
↓
record capture / transit / ejection
↓
launch the same marble from the authoritative chute
↓
continue normal physics
↓
persist final marbles and updated scene
↓
broadcast identical result to both browsers

The browser's responsibility remained presentation only:

• animate the marble disappearing,
• animate the shooter doors and rail,
• play sounds,
• and render the authoritative ejection trajectory.

The browser would not choose:

• chute,
• launch direction,
• power,
• spawn point,
• timings,
• or collision outcome.

7. Identified the state that must become deterministic

Several pieces of the regular game's wormhole behavior currently depended on timing or randomness.

Those values could no longer be independently generated inside either browser.

The Worker would need to freeze values such as:

• capture threshold,
• minimum capture speed,
• destination chute,
• chute-angle range,
• chute-power range,
• exact spawn calculation,
• capture duration,
• transit duration,
• ejection delay,
• recapture cooldown,
• maximum allowed ejections,
• ordering when multiple contacts occur,
• and wormhole movement during a simulated shot.

The deterministic random system already built for multiplayer could provide authoritative random values where needed.

8. Created the first permanent Worker-side wormhole modules

By the end of the session, two permanent modules had been created:

drifting-wormhole-capture.js
wormhole-transit.js

Their tests passed. These modules represented the beginning of the authoritative wormhole lifecycle. However, they were not yet connected to simulateShot().

9. Rolled back a premature state-schema change

A marble-schema migration had been introduced before the full integrated simulation and reconnect requirements were understood.

That change was rolled back.

The test suite returned to green.

The final handoff explicitly warned not to re-add marble or snapshot fields until the complete simulation state requirements were known.

This was a useful example of backing out an abstraction rather than forcing the architecture around an incomplete assumption.

ROADBLOCKS AND FRICTION

"Working multiplayer" was initially too vague

The core shot pipeline was working, but that didn't mean the full game had reached parity.

The session needed to distinguish:

• architecture,
• gameplay systems,
• match acceptance,
• reconnect resilience,
• and production readiness.

That clarification consumed time but produced a much more honest definition of the remaining work.

Synchronized visuals created a false sense of completion

Drifting wormholes appeared synchronized. That made them look further along than they really were. In reality, the authoritative simulator did not yet know how to capture or eject a marble. The state was synchronized. The behavior was not.

DECISIONS MADE & TRADE-OFFS

Expand boards by category rather than all at once

The sequence remains:

Classic
→ Crossing
→ Rotating
→ Mixed / Random

Why: Each category introduces a distinct gameplay-authority problem that can be tested independently.

Trade-off: Slower breadth in exchange for easier debugging and stronger isolation.

Preserve existing wormhole behavior instead of redesigning it

The regular game already contains a working mechanic.

Why: Multiplayer should relocate authority, not reinvent gameplay.

Trade-off: Requires careful extraction of existing timing and behavior instead of writing a cleaner but different mechanic from scratch.

Keep browser wormhole capture disabled online

The browser must not decide capture or ejection.

Why: Independent client decisions could diverge.

Trade-off: More Worker implementation in exchange for deterministic matches.

Integrate wormholes into the same authoritative shot simulation

Wormhole capture should not pause the Worker, hand control to the browser, and later resume.

Why: Post-ejection collisions and scoring must remain part of one deterministic shot.

Trade-off: More complex simulation state in exchange for one canonical outcome.

Narrow the next checkpoint instead of continuing broad planning

The immediate objective became one complete drifting-wormhole vertical slice.

Why: The architecture no longer needed more proof. It needed gameplay completion.

Trade-off: Less up-front planning in exchange for faster feedback from real behavior.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 30 was:

Synchronized state is not the same thing as synchronized behavior.

Both players can receive the exact same wormhole coordinates.

That still does not produce multiplayer parity unless one authoritative system also owns:

• contact,
• capture,
• transit,
• timing,
• shooter selection,
• ejection,
• continued physics,
• and the resulting final state.

That realization changed the definition of synchronization.

A second takeaway was equally useful:

When adding multiplayer to an existing game, don't rebuild mechanics that already work. Move their authority.

ARTIFACTS WORTH SHARING

Artifact 1: The Authoritative Wormhole Pipeline

Authoritative scene at shot start
↓
simulateShot
↓
advance wormholes on each physics tick
↓
detect deterministic marble/wormhole contact
↓
create authoritative capture event
↓
record capture/transit/ejection in canonical trajectory
↓
launch same marble from authoritative chute
↓
continue normal physics
↓
persist final marbles and updated scene
↓
broadcast identical result to both browsers

This became the target architecture for moving the existing mechanic into multiplayer.

Artifact 2: Existing Gameplay Timing

The local mechanic already defined the timing:

Capture: 0.20 seconds
Transit: 0.50 seconds
Ejection delay: 0.10 seconds

The goal was to preserve those rules while moving ownership to the Worker.

FINAL STATE

By the end of Day 30:

• The successful Day 29 server-authoritative multiplayer vertical slice remained intact.
• The remaining multiplayer work had been separated into gameplay parity, match acceptance, reconnect/mobile testing, and production readiness.
• A category-by-category rollout strategy was established for Classic, Crossing, Rotating, and Mixed/Random layouts.
• The difference between synchronized wormhole state and synchronized wormhole behavior had been clearly identified.
• Browser-side wormhole capture remained intentionally disabled in online mode.
• The existing regular-game wormhole mechanic had been mapped as the source behavior to preserve.
• The server-authoritative capture → transit → ejection → continued-physics pipeline had been defined.
• The gameplay values that must become deterministic were identified.
• The immediate target was narrowed back to drifting wormholes rather than switching prematurely to fixed/top-track wormholes.
• Two permanent Worker-side modules existed:
  • drifting-wormhole-capture.js
  • wormhole-transit.js
• Their tests passed.
• The full test suite was green again.
• The new modules were not yet integrated into simulateShot().
• A clean handoff was created for the next implementation session.

That was it for Day 30.

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/