Three games that cannot be added together

The problem

AKBU Odense runs LAN nights for young people in Odense, and an evening covers three games: Minecraft, Fortnite and Among Us. Scores were kept on paper and in someone's head, and the standings existed in exactly one place — with whoever was holding the sheet. Nobody could follow the race while it was running, which is half the point of a tournament.

The real problem was that the three games cannot be added together. Fortnite awards points per elimination and has no ceiling, while Minecraft is judged on creativity, ambition and theme, ten points each and thirty at most. Add the raw numbers up and Fortnite decides the tournament on its own, leaving the build contest as decoration.

On top of that, Fortnite players enter their own results — there is no judge standing behind every screen. And the judges on Minecraft and Among Us walk between the tables with a phone in hand, on a venue network that is not always there.

What I built

Points are converted by placement. In each game a player's finishing position is translated into points from one shared table, so winning Minecraft counts for exactly as much as winning Fortnite, whatever the two games do internally. Ties share the position the way sport usually does — 1, 2, 2, 4.

The rules live in a single file that both the server and the browser load. The standings on the big screen therefore cannot calculate anything different from the server, and there is only one place a rule can be changed.

Self-reporting is kept honest by being public rather than by being locked down. Everything entered is visible in a log, and a judge can annul an entry — but the annulment stays on the record with its reason. With everyone sitting in the same room, that is far stronger than a password.

Judges save from their own phones, and the same round can be saved twice without counting twice: a save corrects rather than appends. On a network where you cannot tell whether it went through, pressing save again has to be safe. No phone is bound to a particular judge, so a flat battery means logging in elsewhere rather than losing a round. Names are normalised before they are stored, so "Jonas", "jonas" and "JONAS" are one participant instead of three.

There is deliberately no build step. The pages are plain HTML, CSS and JavaScript, so a fix in the middle of an event is live in a couple of minutes rather than ten. The database is a shared MySQL instance capped at a hundred connections, and the system is built for that: small connection pools and polling at intervals rather than connections held open all evening.

The whole thing is pixel art set in a typeface from the 8-bit era, because it is a LAN and not a spreadsheet. The font is served from the site's own domain, so nothing has to be fetched from Google in the middle of a tournament.

Where it stands

The system runs as three independent sites: the standings for the big screen, the judges' phone view, and the players' own entry form. They share a database and a rule set but deploy separately, so a fix in one does not touch the other two.

There are no cookies and no tracking. The participants are minors, and nothing is stored beyond what a scoreboard needs: a name and some points.