FORGELY.

I build interactive 3D — playable worlds, not just renders. That means gameplay programming, physics and collision, character controllers, camera systems, AI behaviour for NPCs, animation state machines, and the tooling that lets a level get built without an engineer in the room. I care a lot about the frame budget: draw calls, LODs, occlusion culling, texture atlasing, and profiling until the frame time is boring.

On the visual side I write shaders — surface materials, dissolves, force fields, water, stylised lighting — and build VFX and particle systems. I also handle the full asset path: modelling and UVs, PBR texturing, rigging, baking, and getting everything into the engine at a sane poly and memory budget.

Tools & tech

• Unity
• Unreal Engine
• C#
• C++
• Blender
• HLSL / GLSL
• Shader Graph
• Substance
• Physics & Collision
• Animation Systems
• Level Design
• Profiling & Optimisation

How I work

• Gameplay first. A prototype that feels right before anything gets art-passed.
• Systems, not scripts. Reusable, data-driven components over one-off logic.
• Performance is a feature. Target frame time set on day one and profiled against.
• Tooling pays for itself. Editor tools so designers iterate without me.
• Ship playable. Builds early, tested on real target hardware.

I build web products end to end — interfaces that feel considered and back-ends that hold up. On the front I work in modern JavaScript and TypeScript with React and Next.js, and I put real effort into motion: scroll-driven sequences, WebGL and Three.js scenes, and micro-interactions that make an interface feel responsive rather than decorated. The page you're reading is an example — a 59-frame image sequence scrubbed by scroll on a canvas, with a WebGL particle field behind it.

On the back I build REST and realtime APIs, model and query databases, handle authentication and authorisation, integrate third-party services, and deploy with CI. I hold the whole thing to a standard: semantic accessible markup, keyboard support, reduced-motion fallbacks, Core Web Vitals, and responsive behaviour that's designed for mobile rather than squeezed onto it.

Tools & tech

• JavaScript
• TypeScript
• React
• Next.js
• Three.js / WebGL
• GSAP
• HTML5 & CSS3
• Node.js
• Python
• REST & WebSockets
• SQL & NoSQL
• Git
• Vite
• Accessibility

How I work

• Performance budget up front. Motion never costs the user a smooth scroll.
• Mobile is not an afterthought. Effects tier down by device capability.
• Accessible by default. Semantics, focus states, reduced-motion honoured.
• Animation with intent. Motion that guides attention, not motion for its own sake.
• Own the whole stack. From database schema to the last easing curve.

I work across the machine learning pipeline rather than at one end of it. That starts with data — collection, cleaning, deduplication, filtering and labelling, because model quality is mostly data quality wearing a costume. From there: architecture and training, fine-tuning and parameter-efficient methods like LoRA, quantisation, and evaluation harnesses that measure whether a change actually helped instead of whether it felt better.

My focus is language models and applied LLM systems — retrieval-augmented generation, embeddings and vector search, tool use and function calling, agent loops, structured output, and prompt and context engineering. On the deployment side I handle inference optimisation, serving, batching, caching, streaming and monitoring, so a model that works in a notebook also works under real traffic. This is the discipline that Luminas comes out of.

Tools & tech

• Python
• PyTorch
• Transformers
• CUDA
• Fine-tuning & LoRA
• Quantisation
• RAG
• Vector Databases
• Embeddings
• Agents & Tool Use
• Evaluation
• Inference Optimisation
• Docker
• MLOps

How I work

• Data before architecture. Clean, deduplicated, well-filtered data first.
• Evaluate honestly. Held-out benchmarks, not cherry-picked demos.
• Small and sharp. A focused model that runs beats a huge one that can't be served.
• Reproducible runs. Versioned data, configs and checkpoints.
• Ship to inference. A model isn't done until it's fast in production.

I trade the forex market with a deliberately narrow scope: gold against the dollar (XAUUSD) and euro against the dollar (EURUSD). Two instruments, studied properly, beats twenty watched casually — you learn how each one actually behaves through sessions, news and volatility regimes.

My approach is technical and structural: market structure, support and resistance, supply and demand zones, liquidity and order blocks, trend and momentum, and multi-timeframe confluence — top-down from the higher timeframe bias to the execution timeframe. I also track the macro side that moves these pairs: interest rate decisions, CPI and inflation prints, NFP, central bank policy, DXY strength, and gold's behaviour as a risk hedge. Every trade is planned before entry with a defined stop, target and risk-to-reward, and it's journaled after — because the review loop is where the edge actually compounds.

Approach & tools

• Price Action
• Market Structure
• Supply & Demand
• Liquidity & Order Blocks
• Multi-Timeframe Analysis
• Risk Management
• Fundamentals & News
• TradingView
• MetaTrader
• Trade Journaling
• Backtesting
• Python Analysis

Rules I trade by

• Risk defined first. Fixed percentage per trade, stop placed before entry.
• Two pairs only. XAUUSD and EURUSD — depth over breadth.
• No setup, no trade. Sitting out is a position.
• Journal everything. Entry logic, emotion, outcome, review.
• Process over profit. A good loss beats a lucky win.