Final Year Project

Computer Games Development

Can I Hinder?

Can I Hinder? is a 2.5D top-down action-adventure game with a twist - spectators don’t just watch, they interfere. Using a live web app, spectators can send actions in real time to either help or make things harder.

C++ / SFML 3.0 game client
React + TypeScript spectator PWA
Live help vs hinder audience system
Backend built with ASP.NET and WebSockets

A single-player game shaped by a live audience

The player moves through a series of maps, fighting enemies, collecting keys, and working toward a final boss.

What makes it different is the audience. Spectators join using a session code and send actions live, either helping the player or making things harder.

Every run feels different, as both the player and the audience influence what happens in real time.

4 Gameplay maps
2 Spectator paths
10 Core audience actions
1 Distributed game system

Explore, fight, collect, survive

The core loop is simple...move through maps, fight enemies, collect items, and reach the boss.

The audience changes this at any moment, making each run feel different.

Live help and hinder actions

Spectators join using a session code and send actions in real time. They can help the player or make things harder by spawning enemies, slowing movement, or placing traps.

Support the player

  • Heal the player during combat.
  • Increase movement speed temporarily.
  • Boost attack power.
  • Apply a temporary shield.
  • Unlock God Mode after sustained support.

Disrupt the run

  • Spawn standard enemies near the player.
  • Reduce movement speed.
  • Temporarily lower attack damage.
  • Drop a trap to block progress.
  • Unlock brute spawns after repeated hinder actions.

Combat, items, HUD, and controller support

  • 8-direction movement with keyboard or Xbox controller.
  • Melee combat with directional hitboxes.
  • Item hotbar for potions and collected keys.
  • HUD showing health, session code, and spectator chat.
  • Boss dialogue and turn-based final encounter.

How the system works

01

Game starts

The player enters the game client and a session code is generated for the run.

02

Spectators join

Users authenticate through the web app, enter the session code, and connect to the live session.

03

Actions are sent live

Help or hinder actions are sent as structured JSON messages over WebSockets and broadcast through the relay.

04

Gameplay reacts immediately

The game client applies buffs, debuffs, enemy spawns, and obstacles in real time, changing the run as it unfolds.

Distributed architecture across game, web, and backend systems

Game Client

C++, SFML 3.0, Boost.Beast, OpenSSL, TMX map loading, AI behaviour, combat, HUD, audio, and boss systems.

Spectator Interface

React 19, TypeScript, Vite, and PWA tooling provide the real-time audience control layer.

Relay and API

Node.js WebSocket relay handles message fan-out while ASP.NET Core 8 manages authentication, sessions, and persistence.

Design Focus

The system is designed to keep each part separate, while still working together in real time. This keeps things manageable while supporting live interaction.

What this project shows

Gameplay Engineering

Real-time combat, map progression, boss sequencing, inventory, and state management.

Networked Interaction

Low-latency spectator actions delivered through WebSockets and reflected in the game immediately.

Full-Stack Integration

The project brings together a game client, web app, backend, and database, all working together as a single system.