No One Hires Jr Devs So I Made A Game

TL;DR

The game’s credibility comes from end-to-end engineering: hex-grid tactics rules, fog of war, shrinking battlefield pressure, rendering, and real multiplayer synchronization.

Briefing Cornell Notes

Briefing

A junior-friendly hiring problem turned into a full multiplayer browser game: the project builds a turn-based, one-on-one tank tactics game from scratch to prove real engineering depth—especially in the hard parts hiring managers can’t easily fake. The core pitch is simple: making games forces developers to tackle networking, state synchronization, rendering, UI input, and game rules in ways that don’t show up in “yet another to-do app.” That combination also creates something interviewers can probe—how data moves, how clients and servers agree, and how tricky edge cases get handled.

The game’s design centers on a 2D grid tactics loop played on a hexagonal board. Players move tanks and shoot in one of six directions, with uncertainty added through a limited field of view (fog of war) and a shrinking play area that dissolves hexes and tanks near the center as the match progresses—an anti-stalling mechanic similar in spirit to battle royale pressure. To support the hex grid, the project uses a “clearly superior” hexagonal layout and implements fog-of-war visibility so distant enemy units remain hidden even though they still exist in the simulation.

On the client side, the implementation leans on browser primitives rather than game engines: HTML canvas for drawing and TypeScript for the codebase. Sprites are packed into a single PNG and rendered by copying subregions each frame to create motion. Rendering choices aim for pixelated isometric aesthetics, and the canvas is made responsive without blurring by accounting for device pixel ratio. Interactivity includes dragging for movement and press-and-hold behavior for selecting shooting direction and range limits per turn.

The architecture splits responsibilities into a game state object (plain data), a display driver (rendering), and a game instance (orchestrating updates). Movement and zoom require coordinate translation between screen space and hex grid space, plus pixel-perfect scaling via two base sprite sizes (64 and 96) to keep zoom steps crisp. Pathfinding and move validation use graph search—described as variants of breadth-first search—so the client can highlight legal destinations while the server remains the authority.

Multiplayer is where the project gets most serious. The server is written in Go and uses WebSockets for real-time communication, with JSON chosen for simplicity over a custom binary protocol. Player rooms are managed via Go channels, and state machines help tame a messy web of channel connections. Every move and shot is validated server-side with checks for collisions, range limits, projectile stopping conditions (buildings and tanks), and visibility rules to prevent “wall hacks.” The client receives resolved results and updates instantly, while animation work is treated as a later layer.

By the end, two users can play on different devices, tanks can be destroyed, explosions and smoke are added as sprite effects, and the match pressure system (shrinking map) is implemented. The project also tackles UI complexity: canvas-painted buttons require custom pointer handling, and the input model is designed so actions can be triggered on press rather than release. Deployment is mentioned via a live URL and GitHub source, along with extra features outside the video scope.

The biggest practical setback is iOS reliability: aggressive background throttling and unreliable WebSocket reconnection behavior cause disconnects on window changes, forcing the reconnect workaround to be dropped. The takeaway is less about a single game mechanic and more about engineering credibility—building something hard end-to-end, where networking, rendering, and UI edge cases all have to work together under real constraints.

Cornell Notes

The project turns a frustration with junior hiring into a proof-of-work multiplayer browser game. It implements a turn-based tank tactics game on a hexagonal grid with fog of war and a shrinking battlefield to prevent stalling. The client uses TypeScript and HTML canvas (no game engine), packing sprites into a single PNG and handling responsive rendering, dragging, zoom, and custom canvas-based UI input. Multiplayer runs on a Go server using WebSockets and JSON; the server validates every move and shot (collisions, range, projectile stopping, and visibility) so clients can’t cheat. The result is a working two-player experience, with iOS WebSocket throttling proving a major reliability challenge.

Why does building a game create more interviewable engineering evidence than building a typical web app?

Games force developers to solve interconnected problems: networking (syncing state), rendering (drawing and animation), UI input (dragging, buttons on canvas), and game rules (movement, shooting, collisions). In a to-do app, there’s little to probe beyond CRUD and framework usage. In this project, an interviewer can dig into how WebSockets messages are structured, how JSON is chosen over a binary format, how the server validates actions, and how the client translates screen coordinates to hex-grid coordinates for movement and targeting.

How does the game add uncertainty and prevent players from waiting out the match?

Two mechanics do the job. First, fog of war limits each player’s field of view to a radius around their tanks; distant map areas are darkened and enemy vehicles in shadow remain invisible. Second, the battlefield shrinks over time: each match config includes a shrinking rate that dissolves hexes and tanks within a radius around the center, pushing players into engagements instead of driving indefinitely.

What does “server-authoritative” mean in this project’s multiplayer design?

The server is the source of truth for legal actions. Clients send intended moves/shots, but the Go server validates them using checks like: the projectile can’t exceed range, shots stop when hitting buildings or tanks, tanks can’t move through blocked spaces, and actions can’t violate visibility rules. The server then resolves collisions and returns results to the client, reducing the risk of cheating and keeping both players synchronized.

Why is coordinate translation on a hex grid described as a hard problem here?

Players interact in screen space (dragging and clicking on the canvas), but the game logic operates in hex-grid coordinates. Converting between the two requires correct projections so that dragging to a hex selects the intended grid cell and shooting directions map properly to the six hex directions. The transcript emphasizes that doing these projections for hex grids took more effort than expected.

How does the project keep canvas rendering crisp during zoom?

It uses pixel-perfect scaling by preparing sprites at two base sizes—64 and 96 pixels. Zoom is then achieved by interleaving these sizes so the rendered scale jumps in natural-number steps, avoiding blurry interpolation. This approach preserves the pixelated aesthetic while still supporting zoom interactions.

What broke on iOS, and why was the workaround abandoned?

Testing on an iPhone showed disconnects on window changes. iOS aggressively throttles WebSocket connections in the background, and reconnection attempts after close events proved unreliable with varying exit codes and delays. A more correct approach would be to proactively close and reopen sockets on visibility changes, but that would require rolling out behavior for all clients without a reliable way to deduce browser/client specifics—so the reconnect strategy was dropped for now.

Review Questions

What specific server-side validations are necessary to keep movement and shooting fair in a fog-of-war hex tactics game?
How do fog of war and the shrinking battlefield work together to shape player behavior over a match?
Describe how the project’s canvas UI differs from standard DOM button handling and why that matters for input timing.

Key Points

1
The game’s credibility comes from end-to-end engineering: hex-grid tactics rules, fog of war, shrinking battlefield pressure, rendering, and real multiplayer synchronization.
2
Fog of war is implemented as a visibility constraint so hidden enemy units remain invisible to the client, not just visually masked.
3
The client uses TypeScript with HTML canvas and custom input handling (dragging, press/hold shooting, and canvas-painted buttons) rather than relying on a game engine.
4
Multiplayer uses a Go server with WebSockets and JSON; the server validates every move and shot to prevent cheating and resolve collisions authoritatively.
5
Hex-grid movement requires nontrivial screen-to-grid coordinate projection, plus pathfinding to highlight legal destinations.
6
Sprite rendering is optimized by packing assets into a single PNG and copying subregions each frame, supporting pixelated isometric aesthetics.
7
iOS WebSocket throttling makes background reconnection unreliable, forcing the project to defer a robust reconnect solution.

Highlights

Fog of war and a shrinking battlefield pressure system turn a simple tank duel into a match that can’t be stalled indefinitely.

Server-authoritative validation covers movement legality, projectile range and stopping, collisions, and visibility—so clients can’t “guess” the correct state.

Canvas-only UI means buttons are painted regions, requiring custom pointer event logic rather than DOM click handlers.

Pixel-perfect zoom is achieved by preparing sprites at two base sizes (64 and 96) and scaling in crisp steps.

iOS background throttling breaks WebSocket reliability on window changes, making reconnection a nontrivial engineering problem.

Topics

Multiplayer WebSockets
Hexagonal Grid
Fog of War
Canvas Rendering
Server-Authoritative Game Logic

Mentioned

TCP
JSON
HTML
UI
Go
MP3
CSS
V8
SME