Game development Portfolio Projects

Short answer

What do game development reviewers look for?

Games reviewers want something playable. A build they can run beats any amount of description.

Every brief below includes the problem it solves, who would use it, the features to build first, the stretch goals to leave until the core works, the data model, stack options and an honest time estimate — plus what a reviewer can infer from a finished build.

Pick one. Not three. The most common failure on a junior portfolio is several projects at 60% completion, and the fix is choosing a scope you can finish.

Intermediate

IntermediateFull-stackGame development

Real-Time Multiplayer Quiz

Running a quiz for a society or a class means one person reading questions aloud and manually keeping score.

3 weeks of evenings

Who it is for

Societies, classes, pub teams. Easy to get in front of real people, which is the point.

Build this first

Host creates a room and gets a join code
Players join on their phones without installing anything
Questions appear simultaneously with a countdown
Scoring that rewards speed as well as correctness
Live leaderboard between rounds

Once the core works

Reconnect handling when a player drops off wifi
Question packs that hosts can import
Team mode
Spectator view for a projector

Data you will need

Rooms, players, questions and answers. Most state is in memory during a game; only results need persisting.

Stack options

WebSockets on any stack. Redis if you want rooms to survive a server restart.

What a reviewer can infer

Real-time synchronisation and server-authoritative timing; Managing ephemeral game state; Reconnection and failure handling; Mobile-first interface under time pressure.

Why this works as portfolio evidence

Timing is the interesting problem: you cannot trust the client's clock, so the server has to be authoritative. That is a real distributed-systems idea in a project you can demo live in an interview.

Advanced

AdvancedGame developmentBack-end

Authoritative Multiplayer Game Server

Naive multiplayer games trust the client, so they desynchronise and can be cheated. Doing it properly means the server owns the truth.

6+ weeks of evenings

Who it is for

Players of a small real-time game — top-down shooter, racing, or similar.

Build this first

Server-authoritative game state on a fixed tick
Client prediction with server reconciliation
Interpolation of other players' positions
Lag compensation for hit detection
Room-based matchmaking

Once the core works

Delta compression of state updates
Anti-cheat validation of client inputs
Spectator mode
Replay recording and playback

Data you will need

In-memory game state per room. Persist only match results and player statistics.

Stack options

Go, Rust or C# for the server; any engine or a browser client. UDP or WebRTC data channels where latency matters.

What a reviewer can infer

Network programming and protocol design; Client prediction and reconciliation; Real-time performance under a tick budget; Security thinking — never trust the client.

Why this works as portfolio evidence

Client prediction and lag compensation are genuinely difficult and well documented, so you can work from published techniques and still produce something hard. A playable demo in an interview is memorable in a way a screenshot is not.

Other tracks

Front-end portfolio projects — Interface work where the difficulty is in state, accessibility and performance rather than in the styling.
Back-end portfolio projects — APIs, data modelling, concurrency and the infrastructure that keeps a service standing up.
Full-stack portfolio projects — End-to-end products with authentication, a database and a deployed front end talking to your own API.
Mobile portfolio projects — Native and cross-platform apps, where offline behaviour and platform conventions do most of the judging.
All 30 briefs — the complete library, grouped by difficulty.