The problem I needed to solve
Adding Pasur needs both a correct mode handoff and valid public telemetry. I saw paid entry and reporting as extensions of the shared structure while retaining credit for my teammate.
Implementation in this snapshot
PasurMatchLaunch.Set accepts only two or four players and a valid destination. TryConsume consumes the handoff once and checks the actual scene name, preventing stale selection from silently reaching another destination.
The design decision and its cost
PasurGameplayTelemetry keeps deduplication sets for deals, moves and rounds. TrackAcceptedPlay counts a valid pending action, and Emit catches exceptions so analytics does not stop gameplay.
Current boundaries
Deduplication lasts within the instance and does not alone establish durable server uniqueness. PHP source is now available, but emission failure is neither a gameplay failure nor evidence of future delivery.
Review scenarios and contract meaning
Player-count selection is transient launch data. If it lingers carelessly, a later entry can unintentionally consume the previous choice. Set accepts only two or four players and requires a valid destination; TryConsume consumes the handoff once and checks the actual scene name. Those details let the shared menu and Pasur runner agree on a small contract. In the collaboration account, the rules remain my teammate’s work and this boundary concerns connecting them to the product flow. An internal-coin entry fee should also remain distinct from real-money purchasing or production payment.
Telemetry should derive from accepted actions. Deduplication sets for deals, moves and rounds help prevent a repeated call from creating another event within that instance. That memory does not establish durable uniqueness across every execution. Catching emission errors separates gameplay from reporting failures; failed reporting is neither a failed capture nor a guarantee of later delivery. Bunny Circus Analytics server code is now also present in the supplied source, allowing storage and reporting contracts to be reviewed independently. Its presence alone does not establish live traffic volume or operational quality.
A destination mismatch must not silently apply stale launch data to the wrong mode. The one-use contract helps the runner interpret its input. In reporting, accepted-action counts should not be converted into touch counts: an invalid request is not a valid move. This precision keeps the product connection distinct from my teammate’s rules.
What this stage taught me
For me, integration needs small contracts: the right destination, right mode and events derived from actual public actions. This describes connecting my teammate’s work, without claiming live server quality from Unity code.
