{"id":603,"date":"2025-11-30T22:42:16","date_gmt":"2025-11-30T22:42:16","guid":{"rendered":"https:\/\/mityjohn.com\/?p=603"},"modified":"2025-11-30T22:42:16","modified_gmt":"2025-11-30T22:42:16","slug":"code-chaos-copilots-the-tech-magic-behind-hockey-madness","status":"publish","type":"post","link":"https:\/\/mityjohn.com\/?p=603","title":{"rendered":"Code, Chaos & Copilots: The Tech Magic Behind Hockey Madness"},"content":{"rendered":"\n

At first glance Hockey\u00a0Madness looked like a playful festival, but behind the confetti there was an awful lot of code. Turning a multi\u2011match tournament into an interactive experience required live scorekeeping, authentication, rule management and mobile controls for coaches. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Think of it as building a game engine and a broadcast studio in your browser. In this post we peek behind the curtain \u2014 spreadsheets and all \u2014 to see how the system was architected and how modern tools like Supabase and GitHub\u00a0Copilot helped us ship quickly without losing our sanity (or our sense of humour).<\/p>\n\n\n\n

From idea to architecture<\/h2>\n\n\n\n

The first decision was to use a Vue\u00a03<\/strong> frontend with Vite and Tailwind\u00a0CSS. Vue\u2019s composition API allowed us to organise complex state (scores, timers, boosters) into reusable functions, while Tailwind made it easy to match HC\u00a0Lokeren\u2019s colours and adapt the layout for laptops, tablets and phones. <\/p>\n\n\n\n

For the backend we chose Supabase<\/strong>, an open\u2011source Firebase alternative that offers Postgres storage, authentication, auto\u2011generated REST\/GraphQL APIs and real\u2011time subscriptions out of the box<\/strong>. This meant we could build a live scoreboard without managing WebSocket servers or custom authentication flows.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Real\u2011time scores and boosters<\/h3>\n\n\n\n

At the heart of the app lies a match\u2011control dashboard<\/strong> for officials. When an official adds a goal, penalty corner or card, the change is sent to Supabase via a simple INSERT<\/code> or UPDATE<\/code> and then propagated to all connected clients through the real\u2011time channel. Similarly, when a booster is activated, a record is created in a boosters<\/code> table with its team, effect and expiration time. Subscribed clients update their UI instantly, which is how the public scoreboard displays active boosters and countdown timers. The use of Postgres triggers ensures that effects expire automatically \u2014 once a boosters<\/code> row\u2019s expires_at<\/code> is in the past, a cron function cleans it up and broadcasts a \u201cbooster removed\u201d event.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The match controller also supports Maddies<\/strong>, which modify multiple aspects at once. A single \u201cMaddie started\u201d event notifies the crew to place extra goals or swap balls on the pitch. After the effect ends, the system resets the rules and normal play resumes. This reactive design kept our codebase cohesive: all time\u2011based effects relied on the same subscription mechanism, whether they lasted fifteen seconds or two minutes.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Draft automation and rules engine<\/h3>\n\n\n\n

The pre\u2011tournament draft<\/strong> was automated using a small service that keeps track of which coach goes first in each round and handles bidding. Each bid event validates the coach\u2019s credit balance, compares bids and adjusts credits accordingly. Coaches can view their remaining credits on a live dashboard while making decisions; once a bid is accepted, the player\u2019s team assignment updates for everyone to see.<\/p>\n\n\n\n

Managing rules with data<\/h2>\n\n\n\n

Instead of hardcoding regulations, we built a rule editor<\/strong> where admins can define and reorder cards for game rules, boosters and Maddies. Each rule includes a description, a category and a position in the list. <\/p>\n\n\n\n

The public \u201cgame guide\u201d reads from this dataset, so when we tweak a rule, it updates everywhere instantly. We also store metadata like whether a booster has a countdown and who may activate it. This flexible approach means we can add new Maddies (like Sniper<\/strong> or Golden\u00a0Oldies<\/strong>) without redeploying the client.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Coding with AI: Copilot as pair programmer<\/p>\n\n\n\n

Writing a full tournament system from scratch could have been a slog, but GitHub\u00a0Copilot<\/strong> acted as our silent partner. Copilot uses OpenAI\u00a0Codex to suggest code and entire functions in real time<\/strong>. <\/p>\n\n\n\n

In practice, this meant we could stub out a Vue component and Copilot would propose the reactive variables, API calls and event handlers we needed. When building the Supabase queries, Copilot often generated the SQL and TypeScript definitions, saving us a lot of typing. Of course, we still reviewed and refined the output, but it accelerated development and freed us to focus on game design.<\/p>\n\n\n\n

Building tournaments like Lego<\/h3>\n\n\n\n

Hockey\u00a0Madness isn\u2019t a one\u2011size\u2011fits\u2011all event; some evenings call for a simple round\u2011robin, others need a group stage followed by knock\u2011out rounds. To accommodate this, we built a tournament builder<\/strong>. Each phase (poule, bracket or single match) is stored with attributes like number of groups, teams per group and advancement criteria. <\/p>\n\n\n\n

\n
\n
\"\"<\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Phases are ordered, and the bracket generator uses that sequence to create match schedules. Admins can drag and drop phases and configure them through a form.<\/p>\n\n\n\n

Lessons learned<\/h3>\n\n\n\n