Player movement.
C++ gameplay work defines how the sphere moves and responds. Ground contact, impulse timing, and steering connect the physics simulation to the player’s immediate input.
Selected work / Earlier technical exploration
One More Run
Working through movement, physics, and player flow.
A physics-driven time-trial prototype built in Unreal Engine 5 with C++. I worked on the relationship between player movement, modular tracks, timing, and the feedback that makes a run understandable.
The experience
Speed needs understandable feedback.
The player controls a sphere through a time trial on modular tracks. The central challenge is the relationship between physical movement and player control: acceleration, steering, hops, and contact with the track all influence the next moment of a run.
My movement work includes a custom pawn with a physics sphere, hop impulses and cooldowns, ground detection, slope-based acceleration, and air-control tuning. These are connected parts of the experience. A fast movement system also needs a camera, track, and interface that help the player understand what is happening.
The intended feel is fast and predictable. That is the design goal of the exploration, rather than a claim established through player testing.
My contribution
Connecting the run’s moving parts.
The time-trial loop.
GameMode and GameState work supports the rules of a run. Checkpoints, start and finish detection, lap tracking, and timing provide the structure around movement.
Track & interface.
Modular track pieces support course construction. HUD work communicates countdown and timing information, giving the player feedback about the run alongside the movement itself.
Engineering focus
Give each system a clear responsibility.
The project separates game, player, track, and interface responsibilities. That structure provides a way to work on the movement mechanics without putting the whole time-trial flow into the player object. Track components, run state, and HUD feedback each have a distinct part to play.
The existing project account also documents work on collision complexity, physics sub-stepping, lighting, camera field of view, and profiling. Those concerns make performance part of the development process. They are areas of engineering work, not evidence of a measured frame-rate result.
The useful technical question is how those parts behave together. A change to movement affects what the track asks of the player; a timing or checkpoint event needs to become clear feedback in the interface.
Scope & evidence
An earlier exploration, open to inspection.
The public repository describes a prototype with the core movement, start/finish, checkpoint, and HUD timing loop implemented. It lists further polish, movement work, optimization, and track expansion as next steps. This page keeps that bounded project status.
The source is available for closer inspection. This portfolio account does not represent an independently reproduced build, a gameplay test, or a performance benchmark. The artwork above should be read as project presentation, separate from that technical evidence.
Alongside SPP and FinForFam, One More Run shows the range of my interests: real-time interaction, clear responsibilities between systems, and software whose behavior must make sense to the person using it.
Let’s start a conversation
Have a project or
opportunity in mind?
Get in touch about a role, a product, or Sports Performance Platform.