29th September

Keeping Score, Keeping the Fun

Mario Party has a way of turning a perfectly normal evening with friends into a very serious debate about who got lucky, who deserved the win, and whether that last turn should even count. I love it. The game is chaotic, the accusations are mostly affectionate, and by the next session everyone has a slightly different memory of what happened.

So I built Party Table, a little scoreboard for our Mario Party nights. It keeps the standings, the game history, and a profile for each player in one place. Now there is a record to point to when someone claims they always finish first.

A Small Project with Real Design Choices

The fun part of a side project like this is that there is no assignment brief telling me how much infrastructure to use. Our scores are updated after game nights, not every second, so a database and an admin dashboard would have created more work than the problem needed. I keep the results in one JSON file instead. Add a game, commit the change, and the site can be redeployed with the new standings.

That simple workflow still needs guardrails. The app uses Zod to check the data before turning it into a leaderboard. Game IDs must be unique, players must exist in the roster, and a player cannot appear twice in the same game. Tied placements are allowed, because Mario Party does not owe anyone a neat ranking. Games can also be disabled without deleting their entries, which is handy when a result should stay in the record but not affect the table.

I used Next.js to give the data three views. The front page shows the all-time leaderboard, with total points deciding the order and average points per game alongside it. The game history lets us revisit each session, while the player profiles show wins, average placement, and how each person’s results have moved over time. Players with fewer than five games are marked provisional; one spectacular night should not tell the whole story.

The scoring itself is deliberately easy to explain: first through fourth place earn four, three, two, and one point. There is also an optional multiplier for a game. I wanted the rules to be clear enough that my friends could understand the table without reading the code, even if they still disagree with it afterwards.

Why I Wanted to Build It

I spend plenty of time thinking about models, metrics, and systems for school and work. This was a chance to use the same instincts on something far less serious. I had to decide what the scoreboard should measure, make sure the input data was trustworthy, and present the results in a way people would actually enjoy looking at. It is a small app, but those decisions are real engineering work.

More than that, I wanted to make something for the people I play with. The standings are fun, but the best part is having a record of the nights behind them: the comebacks, the ties, and the inevitable arguments over a stolen star. If Party Table gives us one more reason to get together and play, it has done its job.

  [···············     ]