Comet's Wayfaring Odyssey

3D physics-based puzzle adventure · Unreal Engine 5.3 · PC

My Role

Technical Game Designer
Later acted as Project Manager, coordinating scope and implementation with faculty supervision.

Project At a Glance

Play as a mech-dog trainee on an alien training planet, solving environmental puzzles by detaching your head and using it as a physics controller.

Play Now

Project Information

Type: Graduation project

Genre: 3D physics-based puzzle adventure

Engine: Unreal Engine 5.3

Platform: PC

Team Size: 6 members (5 Game Designers, 1 Artist)

Duration: ~10 months

Highlights

ISART Montréal: “Coup de cœur des Professionnels” 2024

BAFTA: Student Awards 2025 Games - Longlisted

Unreal: Academic Partner Student Showcase 2025

What I Built

My Contributions

I owned the core gameplay feel and the systems that let designers build levels fast.

Built the dual-controller third-person 3C: a tanky mech body, plus a detachable physics head(able to switch seamlessly), tuned mainly for gamepad play (keyboard and mouse supported).
Created a reusable physics interaction framework (“Grabbable + Hands”), using UE5 Physics Control, with data-driven grab points so designers could grab, stack, and throw props without hardcoding.
Built a DataTable-driven dialogue and scripted-event backbone, dialogue lines could trigger doors, water behavior, camera beats, and other level events through a simple interface pattern.
During the Alpha rescope, refactored fragile one-off logic into a more modular Blueprint setup (parent BPs, interfaces, function libraries, event dispatchers), then added debug views and short onboarding notes for the team.
Later acted as project manager and project-level tech coordinator, I helped the team cut scope, align implementation, and actually ship a polished slice.

Key Design & Tech Challenges

Two problems shaped most of my technical work on this project.

Stable, readable physics grabbing on arbitrary shapes
- Problem: fully simulated props look cool, but they can feel messy, hands can jitter, and the “two robot hands” animation can break fast.
- What I did: used UE5 Physics Control, plus a data-driven grab-point setup and a simple solver so the system can pick a good left and right hand pair consistently.
- Why it mattered: level designers could add new props by placing points and tuning a few values, no core logic changes.
Water as environment context, not a binary hazard
- Problem: a kill volume is simple, but it does not create interesting decisions.
- What I did: turned water into a context layer, it slows the mech to warn the player, forces head-only traversal at deeper zones, and pushes players to build paths with props.
- Why it mattered: water became a teaching tool and a puzzle constraint, not just “touch water, you die”.

Inside the Project

Systems, decisions, and how things actually worked.

Project: Comet’s Wayfaring Odyssey (graduation capstone)
Genre: 3D physics-based puzzle adventure
Platform: PC, single-player
Engine: Unreal Engine 5.3
Primary input: gamepad-first (keyboard and mouse supported)
Team: 6 (5 Game Designers, 1 Artist)
Duration: ~10 months, with a major rescope after Alpha
My role: Technical Game Designer, later project manager and project-level tech coordinator
I owned: dual-controller 3C, physics interaction framework (UE5 Physics Control), DataTable-driven dialogue and scripted events, water context system, debug tooling
Shipped: ~15-minute vertical slice, tutorial + 3 themed levels, story-driven scripted events, 2 endings
Recognition: ISART Montréal “Coup de cœur des Professionnels” (2024), BAFTA Student Awards Games longlist (2025), Unreal Academic Partner Student Showcase (2025)

Brief

Comet’s Wayfaring Odyssey is a short physics puzzle adventure, the key idea is a detachable physics head. The body is strong but clunky, the head is small and can roll into spaces, so puzzles naturally push players to switch between the two.

Gameplay Goals

A relaxed, toy-like physics feel (accessible physics sandbox), grab, stack, throw, not precision aiming.
A clear double-controller loop, body for power, head for access and setup.
A short but complete slice, about 15 minutes, like the first chapter of a bigger game.

Personal Goals

Push myself beyond basic UE blueprints into modular architectures (parent BPs, interfaces, function libraries, event dispatchers).
Design and ship from-scratch systems: hybrid 3C, a dialogue backbone, interaction frameworks, and environment-driven 3C behaviour.
Learn to bridge design and programming by writing clear tools and docs for non-programmer teammates.

Production constraints

No dedicated programmer, systems work was done by designers, mostly in Blueprints.
One artist for the whole project, we had to be careful with scope and content load.
After Alpha, we had to cut aggressively and rebuild parts that were too hardcoded.

Things we deliberately cut

Extra level objects that were fragile or too close to existing mechanics (for example head cannon, scale, redundant levers).
More complex ability ideas (chip abilities, auto-jump, detached-mode grabbing), too much for a 15-minute slice.
“True weight” affecting controls, we kept physics mass for puzzles, but removed heavy input penalties to keep it casual-friendly.

Systems I owned

3C and camera: third-person body controller, detachable head controller, camera collision and occluder handling.
Physics interaction (“Grabbable + Hands”): prop parent classes, data-driven grab points, hand targeting, UE5 Physics Control to push, pull, rotate while staying fully simulated.
Dialogue and scripted events: DataTable schema + a reusable dialogue actor, lines can trigger world events via interfaces.
Water context: depth sampling and rules mapping, slowdown warning, separation thresholds, plus puzzle-friendly behaviors.

Key Decisions I Pushed

Use a DataTable + one dialogue actor + a simple “Activates” interface, instead of per-level scripted spaghetti.
Treat props as data-driven objects with multiple grab points and a solver, instead of one socket per prop.
Treat water as a context layer that changes rules gradually, instead of a binary hazard.

What became team standards

Prop inheritance chain and interaction interfaces became the default way to build new objects.
Dialogue + Activates became the standard pattern for scripted events across levels.
Debug visualization became a normal part of tuning and team communication.

TLDR;

I spent most of my time making two systems feel reliable: physics grabbing that looks believable, and water that changes rules in a readable way.

Problem 1

Stable, believable physics-based grabbing on arbitrary shapes

Why it was hard

Fully simulated props are fun, but grabbing can feel messy fast. Hands jitter, props rotate unexpectedly, and the animation can look wrong even when the logic is “correct”.

What made it hard

The system had to work across many prop shapes.
Designers needed a fast authoring workflow, not per-prop special cases.
We wanted it to stay physics-driven, not a fake socket attach.

What I did

Used UE5 Physics Control for more reliable control than classic Physics Constraints, while keeping props simulated.
Gave each grabbable prop a set of data-driven grabbing point components (transforms only).
Built a solver pipeline: filter valid points via traces → score candidates by distance, orientation and priority → select a pair for left/right hands.
Used the solver output to drive fake IK arms: blueprint timelines move “hand targets”, while Physics Control gradually pulls the arm meshes towards the grabbing points.

Bug story, the 180° hand flip

In early previews, hands sometimes flipped 180° before settling on a grab point. The root cause was gimbal lock from interpolating FRotators during “look-at” aiming.

Fix: converted the look-at rotation into quaternions using EZDof quaternion utilities, interpolated in quaternion space, then converted back to FRotator for Blueprints. The sudden flips disappeared, and the preview animation became stable.

Result

Designers could add new props by placing grab points and tuning a few values. The system stayed reusable across levels, and the grab looked stable and readable.

Problem 2

Water as a context layer that changes rules, teaches mechanics, and supports puzzles

Why it was hard

A kill volume is simple, but it does not create interesting decisions. We wanted water to teach rules, affect 3C in a readable way, and still feel fair. It also touches level design pacing, so if it is unclear, the whole game risk feeling confusing.

What made it hard

Water needed gradual rules, not binary fail states(like a kill zone).
It had to coordinate with multiple systems: 3C, head and body separation, scripted events, and level markers.
Floating props can use built-in buoyancy, but the head character needed controllable swimming that feels natural.

What I did

Built the level water using Unreal’s Water plugin (Water Body), used it for visuals and prop buoyancy.
For the head character, implemented a custom depth-based buoyancy model, so the head can float and swim naturally on the surface, and still feel responsive.
Turned water into a rule layer with thresholds:
- shallow water slows the mech as a warning,
- deeper zones force head-only traversal,
- designed moments that encourage building paths with props on land.

Architecture and debug tooling

Used small state machines for water states and player context, driven by depth traces and markers.
Used event dispatchers to broadcast context changes, so 3C and scripted events can react cleanly.
Built debug views:
- trace lines and depth readouts for water,
- gizmos for trigger locations and tuning distances.

Result

Water became part of the puzzle grammar, it teaches separation, creates risk without being punishing, and supports “build a path” play instead of simple failure.

Early 3C Prototypes

I made a few internal prototypes just for feel. The first version was too tanky and too hard to grab things. Over iterations I simplified movement, made grabbing more readable, then locked the core idea, detachable physics head plus playful props.

Pre-Alpha Playtest

The first public playable already had detach and reattach, grabbing and launching, and basic water visuals. Playtests exposed very practical issues, unclear launch flow, camera lag, water rules not obvious, grab feedback too weak. I responded with small changes that made a big difference, clearer grab to launch to release loop, reduced camera lag, better preview feedback.

Alpha & Rescope

At Alpha, my systems were relatively solid, but many other parts of the game were placeholders or incomplete; teacher feedback was harsh, and the team’s morale dropped. Therefore, I scheduled a 1:1 with our instructor to get a realistic diagnosis of what needed to be cut and what a “good enough” final slice would look like.

Back in the team, I used 1:1 conversations with each teammate to map what they had done, why they were stuck, and what they could realistically commit to next.

By the end of the conversations, we re-scoped around:A single 15-minute vertical slice with a few polished levels, while keep the three main loops: physics puzzles, water & separation, and bark commands. Meanwhile, a new, focused tutorial level and a DataTable-driven dialogue system to fill in the world and guide players is also put on the production plan. Which later became one of the most appreciated features in the final build.

Bug & Task Management

We tracked milestones in Jira, and I broke my own tasks into smaller items so I could move fast. Day to day debugging relied a lot on UE tools plus my own visualizers, it saved a lot of time on invisible logic bugs.

Results

We shipped a polished, playable slice, about 15 minutes, controller-first on PC. It includes a tutorial, 3 themed levels, story-driven scripted events, and 2 endings. The project was showcased at ISART’s Graduation Gala, and later recognized through external selections.

Recognition and showcases

Takeaways

Technically, I learned how to make physics systems feel consistent, not just “working”. The solver approach, debug visualizations, and data-driven authoring made a big difference for stability and team speed.

On the team side, the rescope taught me how to turn chaos into a shippable plan. I had to cut features, align people, and rebuild fragile parts into reusable patterns.

After the project, I started learning Unreal C++ seriously, mainly to support cleaner architecture and Blueprint integration in future work.

If I did It again...

I would lock down the interaction/prop architecture much earlier, so we don’t spend time later rewriting hardcoded Level Design Objects into a common framework.

In the meantime, I would push for a mini-Alpha reality check sooner, to align scope before people burn out on an over-ambitious vision.