DIMAS fest - directing one evening across thirty phones

The first version had games. The product needed an evening

AI party games are easy to demo one at a time. Generate a challenge, judge a photo, imitate a voice, show a scoreboard. The harder product problem begins after the first round: what should happen next, what does the host need to prepare, what must remain private, and how does an earlier incident return in the finale?

DIMAS fest became a director rather than a menu.

A host chooses a park, bar, home or festival; a two, three or four hour duration; and an expected crowd between eight and thirty people. Before a room exists, the product assembles a run of show with game moments, guided pauses, a finale and an equipment brief. Guests join from their own browsers by QR or a four-letter code. No app or account is required.

DIMAS fest

Live AI party director

Production surface

SettingPark expedition

Run of show180 min · 12 guests

EquipmentCamera · mic · playback

✓Browser verifiedHost, join and route setup are exercised in production.

○Physical party pendingAutomation does not stand in for mixed-device guests in a real venue.

The setup is operational, not decorative

The live production surface has to answer practical questions before asking the host to trust it:

• How many game moments and story breaks fit this duration?
• Where will a camera, microphone or audio playback be needed?
• What should the host bring for this setting?
• Can the route continue if a permission, provider or piece of equipment fails?
• Is this a host creating a room or a guest trying to join one?

The setup therefore produces a route summary and host brief before the QR appears. A park route can ask for charged phones, a meetup point and a weather fallback. A bar route can account for noise and a quieter recording corner. The experience is generated from the same route registry used during play; it is not a marketing paragraph disconnected from runtime.

One room has several truths

A live party system cannot expose the same state to everyone.

The room has a public layer for the active cue, progress and revealed results. Each player has a private layer for assignments, recordings or ballots. The host has a separate control and evidence layer. Server-only records hold material that must not leak through realtime state. A public QR contains only the join route; host access uses a separate secret boundary.

That separation matters once games use real people and media. A private phrase is not a fun secret if it flashes in another guest's network payload. A recording is not host-only if its storage path arrives in public state. A score is not reliable if an AI response can overwrite it on retry.

The system therefore treats privacy and idempotency as game mechanics, not infrastructure afterthoughts.

AI proposes; the server decides

DIMAS fest uses AI for prompts, text, vision, speech and callbacks. It does not let the model own the score ledger.

A challenge can ask the model for a bounded breakdown. A photo ritual can ask for a critique. A speech game can use transcription and an AI judgment. The final party points are recalculated from server-owned rules, written with stable idempotency keys, and protected against refresh or duplicate requests.

The same principle applies to narrative continuity. Publicly revealed incidents can enter a bounded party memory and return later as callbacks. Private assignments, transcripts, media paths and hidden ballots cannot. Context is quoted as untrusted data rather than appended as an instruction. Invalid model output or provider failure receives a schema-valid deterministic fallback so the evening can continue.

This was the central systems decision: the AI may add texture, but it does not get custody of the party.

The release boundary is narrower than the development tree

The shipped claim in this case is the public production flow: setting, duration and crowd selection; route and equipment briefing; host entry; guest code entry; and the connected room surface.

Automated browser work has exercised host and guest paths, route setup and cleanup. That proves important software behaviour. It does not prove that a first-time host can run a four-hour festival route across mixed iOS and Android devices, weak venue Wi-Fi, backgrounded browsers and real social noise.

The physical evidence gate remains separate:

Browser setup and room flow      VERIFIED
Public production surface         LIVE
Automated mixed-session checks    AVAILABLE
Physical mixed-device party       PENDING
Guest enjoyment / repeat demand   UNPROVEN

A Playwright guest is patient, sober and willing to grant microphone permission on cue. This is useful for regression coverage and not a representative party guest.

Why the host is the primary user

Many multiplayer prototypes focus on the player's game screen. The scarce resource in a long event is the host's attention.

The host needs one next action, not a dashboard of possibilities. They need to know whether to show the QR, wait for device readiness, start the first cue, move to a guided pause or use a fallback. They also need a second trusted device path if the primary phone disappears into a coat pocket or loses the session.

This changed the information architecture. Host readiness, route progress and safe recovery moved ahead of game decoration. The aim is not to eliminate improvisation. It is to keep technical uncertainty from consuming the social energy of the room.

What I was responsible for

I defined the party-director concept, the host/player boundary, the connected-story requirement and the release gates. AI agents built substantial game, route, privacy, scoring and verification code under that direction.

The work was less about asking an AI to invent more games and more about preventing a large generated system from becoming internally inconsistent. Private state, scoring ownership, retries, fallbacks and route progression had to remain legible across many independently implemented slices.

What comes next

The next milestone is not another game count.

It is a documented physical field run with a first-time host, eight or more real guests, mixed phones, an actual venue and no manual database repair. The report should record setup time, permission failures, fallbacks, route completion and whether earlier events genuinely improved the finale. Enjoyment and willingness to host again need direct participant evidence.

Until then, DIMAS fest is a live and technically ambitious party system with browser verification - and an intentionally open field-evidence ledger.

Open the live surface

• Open DIMAS fest