CUE · Same room, same time

An opponent from the room you are already in.

A screen in the venue shows a code. Scanning it puts you in the queue, and each round pairs everyone waiting in one pass. You give your criteria rather than your name, and who you were matched with appears only after both of you accept.

Open CUE What this does not claim

The code is proof of presence. Scanning the code on the venue screen shows you are in the room now, which an app that only knows your location cannot establish.

A service by joygoLive, built here and operated here. Beta.

Design

Three decisions that shaped it

The hard part of pairing people in a room is not the algorithm. It is that the moment you ask for a name, most of the room is already gone, and that the system cannot see most of what happens in that room.

A screen, not a beaconAn earlier generation of venue systems put a radio beacon in every store. A code on a screen needs no hardware beyond the screen, reads the same on every phone, and carries the venue, the activity and the minute, so being in the queue means being in the room.

Only what can be observedThe system cannot tell when you leave, when a game ends, or whether a table is free, because a venue is used by everyone, not only by the people using the system. So none of those are stored. A wait expires on its own, and turning the queue back on is itself the signal that the last game finished.

There is no declineAsking for another opponent removes only the person who asked; the pairing stays open until its deadline. What the other side sees is identical to no answer at all: same wording, same timing. A traceable decline does more harm than none, so the action does not exist.

Entry

Four steps, one of them optional

The code on the venue screen rotates on a timer, so it proves both the place and the time. A returning visitor is recognized for the rest of the session and skips straight back to the queue.

Scan the code on the screenThe camera opens a page. The code itself carries which venue, which activity, and which minute.

Give your criteria instead of your nameOne number and, if you want, the range you would rather play. A returning visitor sees last time's value already filled in, so it is a single confirmation.

Wait for the roundThe screen shows how many are waiting and how long until the next round. Both the venue screen and your phone count down the same clock.

Accept, then meetYou see the other person's criteria and answer whether you can play now. Once both accept, the two names appear on your phone and on the venue screen. Table assignment stays with the venue, as before.

Scanning again is not required to play again. A venue session lasts hours; after a game, one button puts you back in the queue. The system never asks whether the game is over, because it has no way to know.

Rounds

Everyone waiting, paired in one pass

Pairing on arrival sounds faster and is worse: whoever is already waiting wins by default, and a stated preference never gets a chance to apply. Collecting for a minute and pairing the whole queue at once costs a short wait and buys a better set of pairs.

Variety comes firstSomeone you have not met yet outranks someone you played an hour ago. The problem in a regulars' room is rarely a shortage of opponents; it is playing the same person every time.

A preference changes only the orderA preferred range moves candidates up the order without excluding anyone. In a room with three people waiting, a hard filter means no match at all, so when there is no one else, a pairing outside your range is offered and labeled as such.

Waiting time adds weightThe longer someone waits, the more weight they carry, without a ceiling. Without this, people whose range sits at the edge of the room are quietly never chosen: in testing, one player waited fifteen minutes while two others matched each other every round.

No answer means removalWhen a pairing expires, whoever accepted returns to the queue and whoever never answered is removed from it. A phone left in a pocket otherwise occupies a slot and blocks the room.

Identity

Criteria before, a name after

A name is not something you can judge on (it reveals neither skill nor acquaintance), but it is enough to work out who turned you down. The criteria are the opposite: they are the one thing worth judging, and several people in the room share them.

Stage	Criteria	Name	What you are answering
Waiting	—	—	Nothing. The screen shows only how many are waiting and your position
Paired	Shown	Hidden	Whether you can play now, not whether you want this particular person
Both accepted	Shown	Shown	Nothing. Both names are on your phone and on the venue screen

Hiding the name removes the act of declining. You cannot turn down someone you have not been shown, and asking for another opponent stops meaning a judgment about a person. Names are generated, never collected: no real name, phone number or email is asked for at any point.

Use cases

The rules are configuration, not code

Billiards is the first place this runs, not what it is for. What changes between activities is the size of a group and what counts as a good pair; what stays is everything else: the code on the screen, the round, the queue, the two-stage reveal. Pairing algorithms are the library, and a use case is a set of parameters chosen from it.

Activity	What a pairing is	Algorithm	What it asks for
Billiards, table tennis, go	One opponent	Two-person pairing	Handicap or rating
Board-game cafe	The headcount the game requires	Groups of N	Preferred length or complexity
Climbing gym	A belay partner, required for safety	Two-person pairing	Grade and certification
Badminton, tennis courts	Four for doubles	Groups of N	Level
A queue for one table	Whose turn it is	Rotation by arrival	None

The venue is not the unit of expansion; the activity is. One venue can run several: three-cushion and four-ball as separate queues, doubles alongside singles, a bracket on a quiet evening. Each is a set of parameters, and the same room supplies all of them.

Five algorithms, and the input is yours to defineTwo-person pairing, groups of N, rotation by arrival, first-come to capacity, and a bracket. What is asked on entry is defined per use case: a number, a choice, or tags, with which field ranks candidates and whether a preferred range is offered. The score screen is what three-cushion happens to need; another activity gets its own field, or none.

Simulate before publishingA new rule set cannot be debugged on real customers. Virtual participants run over repeated rounds and report how many are left unmatched and how often the same pair recurs. Narrow preferences in a small room can drop matching to zero, and that shows up here rather than on the floor.

Editing a rule never drops a queueSaving publishes a new version; sessions already waiting keep the version they entered under. Versions record how someone entered, and they never split the room: everyone in one venue is matched from a single pool.

The venue only switches it onA venue chooses which activities to run and puts the screen where people pass. It does not tune parameters, assign tables or maintain a queue: the moment a venue has to operate something, a support desk exists.

Limits

What this does not claim

Stating what is out of scope is more useful than stating features, because most of these are deliberate omissions rather than unfinished work.

It does not assign tablesThe system sees only the people using it, while the venue is used by everyone, so a free table cannot be counted. Reporting a number it cannot measure would be worse than reporting none. A pairing means an opponent is settled, not that you can start this second.

It does not judge skillThe criteria are what you state. Nothing verifies them, and nothing is scored, ranked or recorded as a result afterwards. Adding a reward would create a reason to misstate the number, and the honesty of that number is what makes pairing work at all.

It keeps no record of who avoids whomRepeatedly asking for another opponent quietly stops that pairing from recurring. It applies to one relationship, is never counted, never scored, and never notified. An avoidance the other person can be told about is a different product.

It is a beta, in one venueRunning in a single billiards hall for three-cushion play: one activity in one room, which is the right scope for a beta. Whether a room reliably holds enough people at once is the open question, and it is answered by counting on site rather than by argument. Other activities are parameters, but none of them are claimed until one room is proven.