Who owns the clock? Lessons from building a live multiplayer game in Blazor and SignalR

Don Gerard — Fri, 30 Oct 2026 22:12:50 +0000

I build business software on the Microsoft stack for a living. This year I built something different: My Event Bingo, a live bingo game for meetings, presentations and watch parties. A host writes 25 squares from the things that will happen at the event ("someone says synergy", "the dog walks into frame"). Everyone joins from a link or QR code and gets their own shuffled 5x5 card. There is no number caller; the event does the calling.

It runs on .NET 10. One Razor Class Library of about 200 components serves both the website (a Blazor Web App) and a .NET MAUI Blazor Hybrid app for iPhone, Android and Windows. SignalR carries everything live: marks, chat, polls, game start, game over.

Here is what a live multiplayer game taught me that CRUD apps never did.

1. The server owns the lifecycle. Clients only mirror it.

Early on, each client worked out for itself whether the game had started, whether someone had won, whether it was over. That is a recipe for two phones showing two different truths.

Now there is one enum, derived on the server and pushed out:

public enum GameLifecycle
{
    NotStarted,  // before StartTime; the host can still edit squares
    Started,     // StartTime crossed, this player hasn't marked anything yet
    InProgress,  // at least one square marked
    WonByMe,     // this player holds a line; the game continues for everyone else
    Paused,      // host paused; marking is blocked, chat still works
    Ended        // winner limit reached, time limit reached, or host finished it
}

Every transition has a SignalR event. A client may compute the phase locally only on a cold start, before the first push arrives. After that, the server is the source of truth. When a rule changes, it changes in one place.

2. Nobody clicks at 7:00 PM. Something on the server has to.

A game has a start time. At that moment the Join button needs to light up on every waiting phone, even if nobody touches anything. My first version only noticed the start time when a request came in. Visitors sat on a welcome card with a dead button.

The fix is a hosted service, a BackgroundService with a PeriodicTimer:

// Simplified
public sealed class GameLifecycleScheduler : BackgroundService
{
    private static readonly TimeSpan TickInterval = TimeSpan.FromSeconds(15);

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var timer = new PeriodicTimer(TickInterval);
        while (await timer.WaitForNextTickAsync(stoppingToken))
        {
            // 1. Only look at games that have someone connected right now.
            // 2. StartTime crossed and not yet announced -> send "game started".
            // 3. StartTime + 24h crossed -> mark the game ended, then send "game over".
        }
    }
}

Three details turned out to matter:

Filter on live sessions, not database rows. A brand-new game has zero player rows but plenty of connected visitors, and those visitors are exactly who needs the push.
Dedupe "started" on delivery, not on attempt. If the push reached nobody, retry on the next tick for a short window. A duplicate start is harmless because the client handler is idempotent. A missed start is the bug you are trying to fix.
Dedupe "ended" in the database. Flip IsEnded = true before broadcasting. Whichever transaction commits first wins, and the scheduler and a last-second square tap can't both end the game.

Fifteen seconds is the worst-case delay a player can feel, and it costs two narrow indexed queries per tick.

3. A visitor is not a player until they say so

My original page load did two things at once: it fetched the game and generated the visitor's card. A GET that writes. Anyone who opened the link, including a link-preview bot, became a player with a locked card.

Now loading the game is read-only, and joining is an explicit POST /api/bingo/joingame. It is idempotent: call it twice and you get the same card back, never a second card and never an error. The client also disables the button while the request is in flight, but the server does not rely on that.

Rule of thumb I now apply everywhere: if a GET changes state, it will eventually be called by something you didn't expect.

4. Two tabs, one player: last in wins

People open the game link in a second tab or on a second device. If both sessions can mark squares, you get double events and confused boards.

A singleton GameplaySessionRegistry keys sessions by UserId|GameId, gives each registration a monotonic version, and treats the newest one as authoritative. The older session is told it has been superseded, and gameplay commands from it are ignored. It is in-memory and ConcurrentDictionary-based. The few read-then-write paths that ConcurrentDictionary can't make atomic on its own take a short lock.

The same registry answers a question SignalR groups would normally answer: who should get this event? This app routes per connection through the registry instead of using groups, which made it easy to include people who are on the welcome card but haven't joined yet.

5. InteractiveAuto means your component boots more than once

Gameplay uses the InteractiveAuto render mode. A first visit runs on a Server circuit; a returning visit runs on WebAssembly. That is great for load time. It also means a component can prerender, boot on the server, and later boot again in the browser.

What helped was sorting state into three buckets:

Server-authoritative (the game, players, card, lifecycle, winners): re-fetched on every interactive boot, then kept current by SignalR. Never trusted from a client-side cache.
UI preferences (selected tab, mark color): nice to keep, fine to rebuild.
UI-ephemeral (animations, unread counts, scroll position): allowed to reset.

Once the rule is "server state is always re-fetched, everything else is best-effort", the handoff stops being scary. The other half is guarding JavaScript interop: create the DotNetObjectReference once per component instance, dispose it when the component goes away, and make every setup path safe to run twice. Treating "boot" as something that can happen again removed a whole class of ghost-handler bugs.

6. Derive winners from the event log, and decide what "first" means

Several players can win. Who finished first? I don't store a winners table. Every bingo, and every lost bingo, is already logged as a GameEvent, so winners are projected from that log when the game ends.

The interesting decision was the timestamp. A player's finish time is the latest moment they went from "no line" to "holding a line". If you make a bingo, un-mark a square, and remake it later, you are timed at the remake. That keeps the ordering fair without recording which squares formed the line.

What I'd tell anyone starting a real-time Blazor app

Decide early which side owns time, and put a background service behind it.
Make every state-changing call a POST and make it idempotent.
Assume a component will boot twice, and write setup code that is safe to rerun.
Keep the UI library thin. I've been retiring a third-party component suite in favor of small in-house primitives, and every one I replace makes the render-mode handoff easier to reason about.

If you want to see it running, start a free game at myeventbingo.com and open it on two phones. Happy to answer questions about the SignalR or MAUI side in the comments.

DEV Community: Don Gerard