For sphere-affected actors, we sliced collision into multiple adjacent chunks. For example, instead of one large box collision on a plane, we used five smaller box colliders side by side covering the same area.
Result:
-
As the sphere moves, only the chunks that actually overlap toggle, so collision changes feel like they follow the boundary.
-
It’s not perfect (you can still get edge cases like very small invisible collision steps), but it achieved the intended feel: collision behavior looked and felt seamless enough that players trusted it during playtests.
Technical Solutions
The biggest UX problem we hit was collision accuracy at the sphere boundary.
Because overlap is evaluated per component, the initial version had a major flaw: if any part of a collider touched the sphere, the entire collider would toggle. That meant the visuals could show a clean spherical cutoff, but collision would “snap” on/off across the whole object. Players read that instantly as jank: invisible walls, unexpected falls, or surfaces that felt inconsistent.
Design Problems
Since the player could only have one sphere active at any given point, we placed a sphere below the map beforehand. Spawning was causing bugs we couldn’t justify sinking time into, so we went with a reliable approach that still looked intentional.
-
The sphere actor is pre-placed under the level.
-
When the ability is used:
-
We grab the existing sphere, set its scale to 0, then throw a projectile.
-
On projectile hit, we move the sphere to the impact location and lerp it back to full scale so it reads like it spawned there.
-
-
The sphere stays active until the player uses the ability again.
-
Overlap events (BeginOverlap / EndOverlap) drive all state changes inside the active volume.
-
Each overlap change runs a quick relevance gate (Actor Has Tag: WorldChange) before doing any work.
-
For valid actors, the system iterates Overlapped Actors and applies the actual switches: collision/trace responses, material swaps, shadow toggles, and post process changes.
Because our world states were stacked, this approach let us mix-and-match cases:
-
Some actors were pure “exists in one world only” → collision + visuals/materials make them feel present or absent.
-
Some actors existed in both worlds → the object persists, but overlap can still swap its look (Forest vs. Barren materials) without breaking continuity.
Now let's talk about what we ended up making and implementing into the final game. This mechanic was our "pièce de résistance".
Both world states are placed in the same location in the level, and we toggle behavior per object rather than teleporting the player. The sphere doesn’t “move the player between maps.” It’s a local mask which toggles collisions and and visibility.
Inside the sphere’s overlap volume, the system drives three things:
-
Collision toggling to enforce which world is physically real in that space.
-
Material swapping so the correct world state is visible inside the volume.
-
Post process toggles for the inside-volume look.
To keep the system scalable, everything is tag-driven:
-
Actors that participate are marked with a filter tag like WorldChange, so the sphere ignores anything irrelevant (performance + safety), and they also carry a world tag like Forest or Barren. The sphere’s Tag In Mask / Tag Out Mask then uses those world tags to decide what becomes active inside the overlap volume vs. outside it.
-
The sphere holds Tag In Mask and Tag Out Mask to decide what should be active inside vs. outside.
-
Example: if the player starts in Forest, then Tag In Mask = Barren and Tag Out Mask = Forest.
-
Anything tagged Barren becomes visible inside the sphere, and anything tagged Forest becomes “not real” inside the sphere (and vice versa depending on state).
-
Implementation & System Design
Our first version was a straightforward global swap: on a keypress, the player would switch worlds and land in the exact same position in the other state.
What was good about it
-
Extremely readable and easy to learn.
-
Great for quickly validating the “two states, one layout” premise.
Why it wasn’t enough
-
It pushed gameplay into a binary on/off choice.
-
It didn’t create moments that make the mechanic feel unique.
-
Puzzle design started to feel like simple gating instead of localized problem-solving.
After prototyping and a lot of discussion, we moved to the dynamic sphere transition to make the mechanic feel more original and create more dynamic puzzle moments. We kept the full swap as a secondary tool through teleportation shrines, and made the sphere the main way players interact with both worlds.
Prototype 1: Full World Swap (and why we changed it)
-
Make world-switching feel tactical and spatial, not like a binary “mode toggle.”
-
Keep the rule simple: inside the sphere = opposite world rules, outside = current world rules.
-
Make the boundary readable enough that players can trust collisions while moving fast.
-
Support puzzle moments where the player thinks in layers: what exists where, and what happens when the sphere moves or ends.
-
Allow deliberate “risk” gameplay: stepping onto something that only exists in the other world, knowing you can lose it if it leaves the sphere.
Example moment: a moving platform exists only in the Barren world. The player can reveal it with the sphere and ride it, but if the platform moves and part of it goes outside the sphere, that portion loses visuals/collision and the player can slip off. That’s the exact feeling we wanted: you’re managing space, not flipping a switch.
Player Experience Goals
Tethered’s core hook is that the level exists in two states at the same time: an Overgrown, Mythical Forest and a Barren, Mechanical Wasteland. The layout matches, but the rules don’t. A route that’s blocked in one state might be open in the other, and some interactables only exist in one world.
The Dynamic World Transition is the player’s main tool for working with that split. By throwing a sphere, the player reveals a localized area of the opposite world. Inside the sphere, the world behaves as if you’re in the other state, while everything outside stays unchanged. That local contrast is where most of our puzzles and traversal moments come from.
A key part of the design is persistence: if an object exists in both worlds, changes to it carry over. Visually, the same object can still look different between states, so overlap can also drive material swaps (Forest texture vs. Barren texture) without breaking the “same object” rule.
Overview
Dynamic World Transition: Design & Implementation
-
Build the game around a single, readable hook: two world states in the same space, revealed locally through the sphere.
-
Make players curious enough to throw the sphere constantly, using it as a “what’s here?” tool as much as a puzzle solution.
-
Keep the pace calm and deliberate so players can stop, observe, and think without feeling rushed.
-
Design puzzles around spatial relationships across worlds, not key/lock interactions or switch-hunting.
-
Make exploration feel rewarding by letting the other world reveal surprises in familiar spaces.
-
Create standout “cool moments” where the boundary matters (what exists where, and what happens when you move past it).
Player Experience Goals & Design Intent
My Responsibilities
Drop into a split-world level, use the sphere to reveal the opposite world locally, and push through combat and puzzles by exploiting what exists where. Swap worlds at shrines when you need a full state change, then keep advancing until you clear the zone and move on.
-
Co-product owner; proposed the core hook, drove the vision, and aligned the team on scope and priorities.
-
Designed and prototyped the game’s core mechanics.
-
Implemented the Dynamic World Transition feature end-to-end in Blueprints.
-
Built the supporting tag/overlap logic to drive reliable runtime world-state changes.
-
Implemented UI for the project (core screens and in-game feedback).
-
Integrated C++ helper functions into Blueprint workflows to speed iteration.
Core Loop
Contact
About Me
Role: Gameplay & Systems Design
Genre: Spatial Puzzle Solving
Team Size: 10
Time Frame: 7 Weeks
Tethered is a spatial puzzle game set on a planet split between two mirrored dimensions: the lush, living Overgrown and the cold, mechanical Barren. As part of the Restoration Collective, you can fully switch between worlds or deploy an orb that acts as a window into the opposite dimension, allowing you to see and interact across realities. By mastering both transitions, you solve environmental puzzles and work to restore balance to a fractured planet.
CBG Cricket Game
Project Slasher
Scrap Gunsmith
Tethered
Adnan Aqeel | Projects | Tethered
CV
Home
Blueprint Flow
For sphere-affected actors, we sliced collision into multiple adjacent chunks. For example, instead of one large box collision on a plane, we used five smaller box colliders side by side covering the same area.
Result:
-
As the sphere moves, only the chunks that actually overlap toggle, so collision changes feel like they follow the boundary.
-
It’s not perfect (you can still get edge cases like very small invisible collision steps), but it achieved the intended feel: collision behavior looked and felt seamless enough that players trusted it during playtests.
Technical Solutions
The biggest UX problem we hit was collision accuracy at the sphere boundary.
Because overlap is evaluated per component, the initial version had a major flaw: if any part of a collider touched the sphere, the entire collider would toggle. That meant the visuals could show a clean spherical cutoff, but collision would “snap” on/off across the whole object. Players read that instantly as jank: invisible walls, unexpected falls, or surfaces that felt inconsistent.
Design Problems
Since the player could only have one sphere active at any given point, we placed a sphere below the map beforehand. Spawning was causing bugs we couldn’t justify sinking time into, so we went with a reliable approach that still looked intentional.
The sphere actor is pre-placed under the level.
When the ability is used:
We grab the existing sphere, set its scale to 0, then throw a projectile.
On projectile hit, we move the sphere to the impact location and lerp it back to full scale so it reads like it spawned there.
The sphere stays active until the player uses the ability again.
-
Overlap events (BeginOverlap / EndOverlap) drive all state changes inside the active volume.
-
Each overlap change runs a quick relevance gate (Actor Has Tag: WorldChange) before doing any work.
-
For valid actors, the system iterates Overlapped Actors and applies the actual switches: collision/trace responses, material swaps, shadow toggles, and post process changes.
Because our world states were stacked, this approach let us mix-and-match cases:
-
Some actors were pure “exists in one world only” → collision + visuals/materials make them feel present or absent.
-
Some actors existed in both worlds → the object persists, but overlap can still swap its look (Forest vs. Barren materials) without breaking continuity.
Blueprint Flow
Now let's talk about what we ended up making and implementing into the final game. This mechanic was our "pièce de résistance".
Both world states are placed in the same location in the level, and we toggle behavior per object rather than teleporting the player. The sphere doesn’t “move the player between maps.” It’s a local mask which toggles collisions and and visibility.
Inside the sphere’s overlap volume, the system drives three things:
Collision toggling to enforce which world is physically real in that space.
Material swapping so the correct world state is visible inside the volume.
Post process toggles for the inside-volume look.
To keep the system scalable, everything is tag-driven:
Actors that participate are marked with a filter tag like WorldChange, so the sphere ignores anything irrelevant (performance + safety), and they also carry a world tag like Forest or Barren. The sphere’s Tag In Mask / Tag Out Mask then uses those world tags to decide what becomes active inside the overlap volume vs. outside it.
The sphere holds Tag In Mask and Tag Out Mask to decide what should be active inside vs. outside.
Example: if the player starts in Forest, then Tag In Mask = Barren and Tag Out Mask = Forest.
Anything tagged Barren becomes visible inside the sphere, and anything tagged Forest becomes “not real” inside the sphere (and vice versa depending on state).
Implementation & System Design
Our first version was a straightforward global swap: on a keypress, the player would switch worlds and land in the exact same position in the other state.
What was good about it
Extremely readable and easy to learn.
Great for quickly validating the “two states, one layout” premise.
Why it wasn’t enough
It pushed gameplay into a binary on/off choice.
It didn’t create moments that make the mechanic feel unique.
Puzzle design started to feel like simple gating instead of localized problem-solving.
After prototyping and a lot of discussion, we moved to the dynamic sphere transition to make the mechanic feel more original and create more dynamic puzzle moments. We kept the full swap as a secondary tool through teleportation shrines, and made the sphere the main way players interact with both worlds.
Prototype 1: Full World Swap (and why we changed it)
Make world-switching feel tactical and spatial, not like a binary “mode toggle.”
Keep the rule simple: inside the sphere = opposite world rules, outside = current world rules.
Make the boundary readable enough that players can trust collisions while moving fast.
Support puzzle moments where the player thinks in layers: what exists where, and what happens when the sphere moves or ends.
Allow deliberate “risk” gameplay: stepping onto something that only exists in the other world, knowing you can lose it if it leaves the sphere.
Example moment: a moving platform exists only in the Barren world. The player can reveal it with the sphere and ride it, but if the platform moves and part of it goes outside the sphere, that portion loses visuals/collision and the player can slip off. That’s the exact feeling we wanted: you’re managing space, not flipping a switch.
Player Experience Goals
Tethered’s core hook is that the level exists in two states at the same time: an Overgrown, Mythical Forest and a Barren, Mechanical Wasteland. The layout matches, but the rules don’t. A route that’s blocked in one state might be open in the other, and some interactables only exist in one world.
The Dynamic World Transition is the player’s main tool for working with that split. By throwing a sphere, the player reveals a localized area of the opposite world. Inside the sphere, the world behaves as if you’re in the other state, while everything outside stays unchanged. That local contrast is where most of our puzzles and traversal moments come from.
A key part of the design is persistence: if an object exists in both worlds, changes to it carry over. Visually, the same object can still look different between states, so overlap can also drive material swaps (Forest texture vs. Barren texture) without breaking the “same object” rule.
Overview
Dynamic World Transition: Design & Implementation
Build the game around a single, readable hook: two world states in the same space, revealed locally through the sphere.
Make players curious enough to throw the sphere constantly, using it as a “what’s here?” tool as much as a puzzle solution.
Keep the pace calm and deliberate so players can stop, observe, and think without feeling rushed.
Design puzzles around spatial relationships across worlds, not key/lock interactions or switch-hunting.
Make exploration feel rewarding by letting the other world reveal surprises in familiar spaces.
Create standout “cool moments” where the boundary matters (what exists where, and what happens when you move past it).
Player Experience Goals & Design Intent
-
Co-product owner; proposed the core hook, drove the vision, and aligned the team on scope and priorities.
-
Designed and prototyped the game’s core mechanics.
-
Implemented the Dynamic World Transition feature end-to-end in Blueprints.
-
Built the supporting tag/overlap logic to drive reliable runtime world-state changes.
-
Implemented UI for the project (core screens and in-game feedback).
-
Integrated C++ helper functions into Blueprint workflows to speed iteration.
My Responsibilities
Drop into a split-world level, use the sphere to reveal the opposite world locally, and push through combat and puzzles by exploiting what exists where. Swap worlds at shrines when you need a full state change, then keep advancing until you clear the zone and move on.
Core Loop
Tethered is a spatial puzzle game set on a planet split between two mirrored dimensions: the lush, living Overgrown and the cold, mechanical Barren. As part of the Restoration Collective, you can fully switch between worlds or deploy an orb that acts as a window into the opposite dimension, allowing you to see and interact across realities. By mastering both transitions, you solve environmental puzzles and work to restore balance to a fractured planet.
Role: Gameplay & Systems Design
Genre: Spatial Puzzle Solving
Team Size: 10
Time Frame: 7 Weeks
CBG Cricket Game
Tethered
Scrap Gunsmith
Home
About Me
Contact
CV