Under the hood

How Tableland decides

Who gets a table, when your game runs, and what "on track" really means — the full machinery, for people who like knowing how things work.

The problem it's solving

In any area there are only so many tables, and usually more games that want to run than tables to hold them. Tableland's job is to fill the most tables with the most-wanted games. First-come-first-served can't do that — it rewards whoever posts fastest, not the games most people actually want to play. So nothing is booked instantly. Instead, everything is decided together, once a day, when the most information exists.

The drop

Every day at 6 PM, Tableland schedules games happening two days out. It looks at every open game for that date — the hours its players picked, the group size the GM asked for, which venues everyone involved would actually go to, and each venue's open tables and hours — and searches for the combination that seats the most players at once. Not one game at a time: the whole date at once. Moving one game an hour earlier might free a table that lets a second game run; the search considers that.

When the drop publishes, it's final. A placed game never gets moved, shuffled, or re-optimized afterward — your seat notification is an answer, not an estimate. Anything that couldn't be placed stays in the running for its remaining dates, and its GM gets told exactly why it missed ("runs if 2 more players are free Thursday"), not just that it did.

The forecast

The drop only finalizes dates 48 hours away — but a game posted a week out shouldn't sit in silence until then. So every night, after the real drop, Tableland runs the same scheduling process against every future date up to two weeks ahead, as a dry run. Nothing is booked and nobody is notified; it just records where each game would land if that date were decided tonight.

That's what the Forecast line on a game page is: last night's dry-run result, in plain English.

• "On track to run Saturday" — the game got a table in last night's dry run of that date.
• "has held for 3 straight days" — it's gotten a table in the dry run three nights in a row. One good night can be luck; a streak survives new games and shifting player hours, so longer streaks mean a placement that's getting hard to dislodge.
• "currently landing 7:00 PM at Public Assembly" — the specific time and venue only appear once they've been identical for at least two nights. If the dry runs are still bouncing between answers, the forecast deliberately stays vague rather than telling you a time that might change.

A forecast is honest but not a promise — players keep joining and leaving and new games keep posting, and the real answer arrives at the drop, 48 hours before game day. What the forecast tells you is which way the wind has been blowing, and for how long.

Nerd corner

For those who want the actual mechanics:

• The schedule search is a hand-rolled branch-and-bound solver: it maximizes players seated, breaking ties toward games that would otherwise have fewer chances left, and respects hard constraints exactly — a session must fit inside the GM's window, every seated player's picked hours, the venue's opening hours, and a free table for the whole duration.
• Each date's search is seeded deterministically from the date itself, and the nightly dry run uses the same seed the real drop will use. A forecast isn't a simulation of a similar universe — it's literally tonight's answer to that date's puzzle, given tonight's information.
• Dry runs write nothing but their own results: no seats, no notifications, no holds on tables. The 48-hour drop remains the only thing that commits anyone to anything.
• What's never in the algorithm: payment, priority, or promotion. No one can buy a better placement — the solver optimizes seats, full stop.

Questions this page didn't answer? Tell us — this page exists so the scheduling never feels like a black box.