A high-performance C++ system built for a fictional client, Nexus Logistics, to centralise inventory and order processing across 5 warehouses that had previously each run their own inconsistent management system. The design follows a producer-consumer model: five warehouse threads load orders into a shared queue, then a user-selected number of worker threads (1-32) drain and fulfil them concurrently against a central inventory.

My contribution

I led the project and was responsible for the high-level system design: the overall producer-consumer architecture and how the OrderPool, InventorySystem and thread pipeline fit together. I then built the entire CLI: the full 9-option menu, every product/search/sort sub-menu, and the input-validation layer (safe int/double readers that recover cleanly from bad input instead of leaving cin in a broken state). Together these cover all the user-facing flow that sits on top of the class hierarchy the rest of the team designed.

I also took the AnalyticsManager through a full overhaul, from a handful of basic totals into a proper reporting engine: 18 metrics across global and per-warehouse scope (revenue, lost revenue, best-selling item, and category/type breakdowns of revenue, quantity, failure rate and average price), each exportable to its own CSV for Excel/Power BI, all runnable from a dedicated Analytics sub-menu I added to the CLI.

System highlights

• An abstract Product base class with Taxable, Discounted and Standard subclasses, using virtual functions so pricing logic resolves correctly through a shared_ptr<Product> at runtime.
• Thread safety via a coarse-grained inventory mutex, a mutex + condition variable on the order queue (so workers sleep instead of busy-waiting), and std::atomic<int> for lock-free order-ID generation.
• A bonus Qt6 GUI (dashboard, inventory, analytics, orders) layered on top of the CLI backend through an adapter, so both interfaces share the same core logic.
• Verified deadlock-free under test: final stock totals matched expected values exactly across every run at up to 32 concurrent workers.

Measured performance

Processing 1,300 orders across a 999-product, 11-category catalogue scaled from ~20,000 ms on a single thread down to ~650 ms at 32 threads (a ~30× speedup) before plateauing as inventory-mutex contention became the bottleneck.

A full-stack database application modelling the day-to-day operations of a travelling amusement park (customer admissions and loyalty cards, employee rostering, ride/show/stall management, maintenance logging and financial transactions), all served through a role-based Java Swing front end over MySQL.

My contribution

I planned the business scenario that the whole database was modelled from: working out how a travelling carnival's customer admissions, loyalty smart cards, employee roles, attractions and financial transactions actually relate to one another, before any table existed. That scenario became the spec the EERD and schema were built against.

I then built the entire Java Swing front end and its visual design. Login is a custom-painted screen I wrote directly on Graphics2D: a drifting starfield of 180 twinkling stars, 18 looping carnival “sparks”, and a slowly shifting dual-tone gradient behind a rounded glass card, all hand-animated on a Swing Timer, no game engine or extra library involved. On top of that I built the generic EntityConfig-driven CRUD engine that every other screen is built from, the role-based routing between the four account types, the four-step Sales pipeline, and the Reports screen.

System highlights

• 22 tables, 3 views, 2 stored procedures and a full set of triggers, seeded with sample data and four dedicated MySQL accounts (admin, sales, maintenance, guest) that each open a different role-specific screen.
• A generic CRUD engine: every entity is declared once as metadata (table, fields, dropdowns, foreign-key bindings, subtype rules) and a single EntityCrudPanel builds the form, grid and SQL for all 21 entities: adding a new entity is a metadata entry, not a new screen.
• A four-step Sales pipeline (identify customer → log admission → issue an access pass → summary) where the admission and pass insert as one atomic transaction, so a half-completed sale is never left behind.
• Five concurrent SwingWorker-backed reports joining three or more tables each (revenue by location, ride maintenance cost, stall stock, staff distribution and top customer spend), so the UI never blocks while they run.

All queries are parameterised throughout, and MySQL's own per-role privileges provide a second line of defence: even a bug in the Swing client can't issue a statement the account isn't allowed to run.

A head-to-head comparison of three generations of NLP text classifiers (a traditional statistical model, a recurrent deep-learning model, and a pre-trained transformer) on the same binary sentiment task: predicting whether a Steam game review is Recommended or Not Recommended.

My contribution

I led the project and, in addition to training our BERT model, built the entire data pipeline that fed all three models (extraction, cleaning, balancing and splitting) as a standalone notebook the rest of the team's model notebooks all pointed at, so every model trained and tested on identical data.

Extraction: Steam's API caps each request at 100 reviews and paginates with a cursor rather than an offset, so I wrote a loop that walks that cursor per game across 100 selected App IDs, targeting 500 positive and 500 negative reviews each. I collected by class as I went, not after the fact, because some games skew heavily positive and pulling reviews blind would have starved the negative class. Requests are rate-limited with time.sleep() to avoid throttling, and every write checks Steam's own review ID before saving, so re-running the script after a timeout or crash never reintroduces a duplicate.

Cleaning: the raw pull (~94,900 reviews) needed several passes before it was trustworthy training data: stripping reviews mangled by Steam's profanity filter (which replaces swearing with a symbol that corrupts the surrounding text on read), removing links and spam patterns that carry no sentiment signal, running langdetect per review because Steam's own language tag reflects the client's UI language rather than the review text (this alone cut 21,950 reviews), stripping emojis the tokenisers can't meaningfully use, and de-duplicating by exact text (~18,000 reviews) so the same review couldn't land in both the train and test split and inflate accuracy.

Balancing & splitting: the cleaned data was balanced to an even 60,000 reviews (30k positive / 30k negative) and split 70:30 with stratification, so class balance held in both the training and test sets.

For my own model, I fine-tuned BERT (bert-base-uncased) with AdamW, a linear warmup schedule and gradient clipping on a 6GB GTX 1060, and restored the best-validation-loss checkpoint to counter overfitting after epoch 1.

Results

• BERT: 88.73% accuracy, 89.22% F1, the best of the three, at the cost of ~80 minutes' training time versus 35 seconds for the LSTM and 0.03 seconds for Naive Bayes.
• Naive Bayes (84.11% accuracy) and BiLSTM (84.05%) landed almost identically despite very different architectures: Steam reviews are short (median 10 tokens) and lexically driven, which limits how much sequential context modelling actually helps.
• BERT's ~4.6-point F1 lead over both baselines came from its pre-trained contextual representations, which handle negation and phrasing-driven sentiment that a bag-of-words or from-scratch embedding can't.

A local player for FLAC libraries, inspired by the old Samsung TouchWiz Music Square, except instead of relying on genre tags or an online lookup, it plots every track by actually analysing the audio itself. Everything runs locally: no files, tags or audio ever leave the machine.

How the mood coordinates work

For each track, librosa extracts tempo, loudness (RMS), onset rate, spectral centroid, and a tonality “mode score” from a chroma vector compared against major/minor key profiles. These five raw features are then z-scored across the whole library (so “loud” or “bright” is always relative to your own collection) and combined into two weighted axes: arousal (tempo-led) for the x-position and valence (tonality-led) for the y-position, each compressed to -1..+1 with a tanh squash.

Interface

• Click anywhere on the square to drop a probe and build a mix from the nearest-sounding tracks, or drag to sweep a path through a sequence of moods.
• Tracks render as their own album art clipped to a circle; the whole UI takes its colour from whatever's playing, sampling the art down to a tiny canvas and deriving a background wash and accent palette from it, Material-You style.
• A Flask server streams the audio and serves the analysis; the frontend is vanilla JS and Canvas, with art double-cached (server-side and via the browser's Cache Storage API) so reloads are instant.

The analyzer is resumable and parallelised: it samples ~60 seconds per track from ~30% in, skips already-scored files on re-runs, and falls back to a slower crash-isolated mode if a corrupt file would otherwise take down the whole batch.

Break the armour. Take the core. Choose the ship's fate. CoreBuster is a science-fiction first-person shooter developed in Unity 6 for COMP307 Computer Graphics. The player awakens aboard a malfunctioning spaceship overrun by hostile robots, fights through interconnected industrial chambers, and ultimately decides between escaping the ship or confronting its unstable reactor core.

The signature mechanic: Core Bust

At the centre of the combat system is Core Bust, a first-person execution mechanic. Armoured enemies contain unstable energy cores. Once their armour has been destroyed, the player can approach and execute them, physically extracting the exposed core through a synchronised animation. A successful execution restores health, but leaves behind a toxic gas cloud that creates a new environmental hazard.

The mechanic is implemented through coordinated gameplay state machines involving ArmouredEnemy, CoreExecutionTarget, CoreExecutioner and UnstableCore. Armour destruction extracts geometry from the animated mesh and converts it into physical debris rather than simply hiding the armour.

Weapons and combat

• The Blaster: the player's primary firearm, used for conventional combat and breaking enemy armour.
• The Disassembler: charged through successful executions, this sidearm electrocutes and temporarily immobilises enemies while exposing their cores for further executions.
• XR-7 Armour Buster: an unlockable rocket launcher whose explosions strip armour from nearby enemies, preserving the game's execution-focused combat system.
• Movement: sprinting, crouching, sliding, jumping, wall-running and dodging provide mobility during combat encounters.

Enemy AI

The game features four main enemy classes across nine variants, including armoured Cyber Soldiers and Elites, standard ground robots, and airborne HoverBots. Enemies use NavMesh navigation, room-aware pathfinding, line-of-sight detection, telegraphed attacks and procedural attack animation.

Enemy behaviour reacts to armour damage, electrical status effects, the player's position and the ship's security doors. Reinforcements arrive through warp-in effects during lockdown encounters.

World and progression

The spaceship is designed as a continuous level with five connected zones, including a tutorial wing, workshop, reactor chamber, turbine hall and final Boss Hall. Security doors and keycards govern progression between areas, while terminals initiate lockdowns and waves of enemies.

The game offers two endings. The player can survive a timed escape sequence or enter the final chamber and dismantle the giant reactor core through a multi-stage encounter involving three consoles and destructible armour layers.

Computer graphics engineering

• 18 custom shaders: hand-written ShaderLab/HLSL implementations for energy fields, procedural armour damage, toxic gas, electrical effects, reactor beams and animated materials.
• Procedural space environment: a GPU-generated nebula skybox featuring a black hole, gravitational lensing and an animated accretion disk.
• First-principles asset generation: industrial machinery, tanks, reactors, turbines, pipes, weapons, environmental signage, textures and audio generated using Unity editor tools and Python scripts.
• Ray-traced ambient occlusion: a custom rendering implementation with temporal accumulation and depth-aware filtering.
• Visual effects: animated energy fields, electrical arcs, armour cracks, volumetric-looking gas effects, reactor instability and procedural particles.

Architecture and optimisation

Gameplay systems are organised into separate assemblies for shared infrastructure, gameplay, artificial intelligence, user interfaces and rendering.

A custom ZoneStreamer system reduces rendering overhead by suppressing renderers in rooms that are not currently visible, while preserving physics and AI simulation. The project also includes configurable graphics quality profiles and rendering optimisations for constrained hardware.

Development context

Developed by Cosmic Studios as a five-person COMP307 group project at the University of KwaZulu-Natal. CoreBuster combines real-time computer graphics, interactive gameplay, procedural content creation, game AI and software engineering in a single playable project.

My biggest project to date. Language models write plausible code that calls web APIs which do not exist, at versions that have been retired, with parameters the provider never documented. I led a team of five to test whether an agent can stop those REST API hallucinations from reaching the user, guided by one idea: a Confident Agent is not one that is always correct, but one that knows when it should not be trusted.

My contribution

I led the group and shaped the project end to end:

• Overall architecture and design: the shape of the whole system, from how the model, the verification tool and the release decision fit together to how the experiment is structured around them.
• Attachment point: I chose where the verifier plugs in. It runs as an in-loop tool the model calls through function calling, so the thing we measured is the package a developer would actually run, rather than a post-hoc script or a pipeline of more models that could hallucinate themselves.
• Benchmark and evaluator design: the 1,000-task benchmark with its executable answer key, and an independent sandboxed evaluator that shares no code with the agent, so the agent's blind spots could not become the experiment's.
• Running the tests and benchmark runs: the verifier and benchmark checks, plus the paired runs of the baseline and the agent.
• Art style: the visual identity of the project, from the navy, yellow and blue palette to the banners, slides and README.

How it works

A local model (Qwen3.5-9B) is paired with a deterministic validation tool that parses the generated Python without running it and checks every API claim across six layers (imports, identifiers, access point, input contract, output contract and security context) against frozen, hashed OpenAPI specifications. The evidence is summarised in an Evidence-Weighted Confidence Score, and a decision policy then delivers, flags, corrects once, or withholds the code. Hard verification constraints, not the score, decide whether anything is released.

The experiment

• A benchmark of 1,000 Python tasks over six public REST APIs, generated from pinned specifications. Of these, 990 were scored.
• A paired comparison of the unmodified model against the agent at three quantizations (2,970 task pairs).
• A pre-registered analysis plan, exact McNemar tests, cluster-bootstrap intervals, manual audits of the answer key and evaluator, and a cost analysis in time, tokens, energy and Rand.

Results

• Hallucinated code reaching the user fell from 50.8–55.2% to 1.6–2.3%, while correct code rose from 24.9–36.9% to 50.4–51.5%.
• 83% of baseline hallucinations (1,303 of 1,562) were stale or extrapolated API versions: the model reproduces the versions that dominate its training data and invents version numbers it has never seen. Nothing in its weights records that an API has moved, so the fix has to be external evidence.
• The protection has costs: the agent abstains on 38–40% of tasks and takes about six times the time and energy of the baseline. Verification establishes conformance to the API contract, not that the code does what the user asked.

The site you're looking at right now. A single-page Jekyll portfolio with sliding panels for About Me, Projects and a full Detailed CV, all themed and colour-matched to my actual CV rather than a generic template look.

What it's built on

Rather than starting from a blank page, I built this on top of two open-source Jekyll templates and reworked both substantially:

• The overall one-page shell (the sliding panel system, video background and layout grid) started from jekyll-uno by Josh Gerdes, as extended into jekyll-uno-timeline by Thomas Zühlke, both MIT-licensed. Almost none of the original styling remains; the panel system, project carousel, colour theming and CV integration are my own additions on top of that base.
• The Detailed CV page is built on the Orbit resume/CV template by Xiaoying Riley (themes.3rdwavemedia.com, Creative Commons Attribution 3.0), restructured into the sidebar-plus-main layout you see and recoloured to match my actual paper CV, then embedded into the main site as its own popup panel.
• Icons throughout are Font Awesome Free. The site is built with Jekyll and hosted on GitHub Pages.

What I actually built

• A shared sliding-panel system (About Me, Projects grid, and every individual project) with consistent open/close animation, keyboard (Escape) handling, and swipe support on mobile.
• The CV page: a from-scratch sidebar-plus-main layout matched to my real CV's colours, with per-project accent colours picked directly from each project's artwork rather than a fixed palette.
• The Detailed CV popup embeds the standalone CV page in an iframe so it stays a real, linkable page on its own while still opening in-place like every other panel.
• All the copy, project write-ups and colour decisions on the site are mine, iterated over several rounds to fix layout bugs, improve contrast, and keep the design consistent as content was added.