How Hack Days Help Us Build Better Digital Experiences

This is where team members can explore new technologies, test ideas, and build without the constraints of a client brief. This gives us the chance to experiment, learn unfamiliar software, and develop skills that often carry over into future projects. 

I recently saw an email that inspired my focus for the hack day. It was about an upcoming game jam, and it made me nostalgic about when I used to develop short games as a hobby. 

For a short experiment, I decided to build a game with HTML Canvas (something I’d never used seriously before) and push my JavaScript skills by building something interactive from scratch. The main aim was to keep it small, simple, and replayable. 

I came up with the name Kill the Broadcast first, and the rest of the game grew from there. The premise: a grid of televisions is broadcasting. You need to shut them down before the signal overwhelms the system. Three enemy types keep things interesting – eyes, the basic enemy you simply click to kill; mouths, which spread to neighbouring tiles if left unchecked; and hands, which reach out and randomly activate other TVs, accelerating chaos across the board.

I chose HTML Canvas and vanilla JavaScript deliberately. Canvas gives you a blank surface and gets out of the way. For a game built around drawing custom TV sets with CRT effects, scan lines, and flickering glows, that low-level control was exactly what I needed.

The aesthetic direction came from the title itself. Kill the Broadcast felt like it belonged on a late-night channel, transmitted through an old, dying CRT. That became the core visual language: slight glow, noise grain, horizontal scan lines, the slight warp of an old screen.

The hardest design constraint was resisting the urge to add more. More enemy types, more mechanics, more UI. Every addition had to earn its place by making the game more fun, not just more complex.

A game that’s too easy is boring. A game that’s impossible is frustrating. Getting the curve right required me to think carefully about when new threats are introduced. Flooding the grid with every enemy type in the first ten seconds would kill the experience before it started.

I wanted the arcade loop – play, die, immediately want to go again. That means fast restarts, a score you can chase, and enough randomness that no two runs feel identical. The scoring system exists specifically to give players something to compare and beat.

The game runs on a time tracker that gates enemy types behind thresholds. No mouths spawn before 30 seconds. No hands before 60. This gives new players time to understand the core mechanics before layering in the spread and acceleration mechanics that define the mid and late game.

Each enemy type required its own logic:

Mouths use a custom spread function. When a mouth TV activates, it scans its neighbours and, after a countdown, begins infecting adjacent tiles. The countdown is critical to ensuring that the difficulty is maintainable.

Hands randomly select any inactive TV on the board and activate it. Mechanically, it effectively doubles the activation rate, which is why it’s the last type to appear.

The three enemy types each demand a different interaction to neutralise them: eyes require a click, mouths require a click and hold, and hands require hovering.

These are designed to create small moments of decision-making. When a hand and a mouth activate simultaneously, which do you prioritise? Do you deal with the spreading mouth or suppress the hand before it wakes up something worse? That tension, generated from three simple input types, is the core of the game’s strategy.

A custom rendering function builds each TV from scratch on the canvas – bezel, screen, the glow of the tube, the type-specific icon overlaid on top. Different enemy types use distinct colour palettes, so you can read the board state at a glance without needing to process icons consciously.

The CRT effect layers noise grain, horizontal scan lines, and a subtle screen curvature over the top of each tile.

The game’s title gets its own treatment: a slight rotation and a CSS keyframe flicker, somewhere between a neon motel sign losing its charge and a broadcast signal dropping out. It sets the tone before a single TV appears on screen.

Building small is a skill. It’s tempting to keep expanding scope – add a new enemy, add a power-up, add a story. Kill the Broadcast works because it doesn’t do any of that. Every mechanic serves the core loop. Every visual choice serves the aesthetic. 

The other thing: randomness is a feature, not a shortcut. Math.Random() isn’t lazy game design – when applied with thought, it’s the engine of replayability. No two runs of Kill the Broadcast are the same, and that’s why you want to immediately start another one.

The game is simple, has a lot of personality, and is easy to play but difficult to master. Give it a go – see how long you can keep the broadcast offline.

Although the project took the form of a game, the principles can be applied to our client work. Breaking problems into smaller components, thinking carefully about user experience and interaction, balancing complexities with usability, and building something engaging without being too overwhelming are all skills that can be brought into any development project. 

Here’s to the next hack day.