To Pierce Eternity — Hyperluminal X
Context
To Pierce Eternity is a first-person horror game developed in UE5 for Hyperluminal Games as part of DES512 at Abertay University. The brief was to create a game with a rogue HUD that feeds the player false information and objectives.
I worked as Gameplay & Systems Designer within a team of 12, owning the core mechanics, systems design, and documentation pipeline, while also taking full ownership of the level lighting, atmospherics, and cinematics as gameplay vessels rather than purely aesthetic elements.
The Design Foundation
The game was built around a single pillar: the HUD lies, the companion misleads, but the environment tells the truth. Every system I designed had to serve that principle. Mechanics, lighting, and cinematics all exist to reinforce or subvert the player's trust in the information they're given — the goal was never to make the player feel cheated, but to make them feel the weight of figuring out what to trust and when.
Deceptive Information Systems
The HUD actively misleads. Every UI element, every companion instruction, and every objective is a potential lie. Environmental truth-telling is the only reliable signal — requiring the player to learn what to trust.
Interlocking Systems Design
Each mechanic creates the need for the next. The headlamp drains → the player recharges at a station → the station disables the HUD → the player discovers environmental clues. No mechanic exists in isolation.
Production at Scale
First time working under genuine production pressure, for a real client, within a 12-person multidisciplinary team. Owning documentation pipelines and cross-discipline communication alongside creative design work.
Official Trailer
Design Deep Dive
Game Flow & Iteration
From Full Vision to Focused Execution
Result: A tighter, more impactful game flow. The climactic chase event carries significantly more narrative weight as a singular moment than it would have as a repeated sequence.
Intention: Before any implementation work began, I mapped out the full game flow as a diagram the team could work from. Two versions exist because the design changed after our first client meeting — the reoccurring chase sequence was removed, scope was tightened, and the updated flowchart reflected those decisions cleanly.
Process: A chase sequence recurring after every puzzle without enough variation would have lost its impact over time. Repositioning it as a single climactic event made it carry significantly more narrative weight — and the rest of the game flow remaining largely unchanged confirmed the initial vision was structurally sound.
Headlamp Mechanic
From Toggle to Loop
Result: One mechanic created the need for the other. The headlamp battery is what made the short circuit station loop feel natural rather than forced.
Intention: The headlamp started as a simple on/off toggle. While functional, it was too safe — a player who could leave it on indefinitely had no reason to engage with the short circuit station at all, which broke a core part of the intended loop.
Process: Adding a battery element that drains while the headlamp is in use changed that entirely. With the battery draining, the player is pushed to recharge at short circuit stations. Using a station disables the HUD temporarily — revealing clues, text, and environmental details that the HUD was obscuring.
Chase Sequence
Agency Inside Tension
Result: Every obstacle in the underbelly presents the player with a real decision — not a survival check, but a trust check. Cody is still present, still misleading.
Intention: The chase sequence was designed around one core principle — the player should feel agency and tension simultaneously. Rather than a straightforward run-to-survive experience, every obstacle presents the player with a decision that can either help or hurt them.
Process: The steam pipe mechanic makes this explicit. Two valves are visible. Cody highlights one. Ignoring Cody is the correct choice — triggering the upstream valve sends the steam behind the player and slows the entity. Following Cody's guidance blocks the player's own path. The same logic extends to the PCU spilled liquid interactions throughout the sequence.
Tutorial Segment
Onboarding Without Instruction
Result: The HUD disabling during the short circuit interaction introduces the wall writing mechanic and plants the first seed of distrust in the companion before Puzzle 1 even begins.
Intention: The tutorial wasn't in the original plan. It emerged from playtesting in Week 7, when it became clear that Puzzle 1 was overloading the player with too many mechanics at once. The solution wasn't to simplify the puzzle — it was to redistribute that onboarding load to an earlier, lower-stakes environment.
Process: It couldn't feel like a conventional tutorial. The player wakes up disoriented and weak, and every mechanic introduction had to feel motivated by the world rather than by instruction. The sequence — headlamp, healing, short circuit station, door and terminal — was ordered so that each action created a natural reason for the next.
From Observation to Decision
Playtesting ran consistently from the first playable prototype through to the final weeks. My focus in each session was identifying friction that felt artificial and damaging rather than intelligent and intentional — then flagging it, discussing it with the team, and proposing a specific change.
| Session | Observation | Decision |
|---|---|---|
| Week 7 — Client Meeting | Puzzle scope too wide, experience too long | Puzzle 3 cut from scope entirely |
| Week 7 — Internal + Client | Order of operations consistently blocking players in Puzzle 1 | Mechanic removed, tutorial designed from scratch |
| Week 9 — Playtest | Players not connecting stencil board to colour wheel in Puzzle 2 | Board interaction redesign proposed |
| Week 12 — Client Meeting | Board movement creating unnecessary friction in Puzzle 2 | Direction constrained to move toward wheel only |
In-Engine Gallery
What I Learned
This was the first project where I worked under genuine production pressure, for a real client, within a large multidisciplinary team. The areas I grew most in — cinematics, lighting, cross-discipline collaboration, and design documentation — weren't all areas I had prioritised going in. Some of that growth happened because the project demanded it and I stepped into it.
The gaps are just as clear. Knowing specifically where my process fell short helped me understand the starting point to begin fixing it.
What the project built
- Cinematics as a gameplay tool, not just atmosphere
- Level lighting as a mechanical layer with real player stakes
- Cross-discipline communication in a 12-person team under client pressure
- Design documentation that actually drives team decisions
Where the process broke down
- Limited in-engine prototyping of mechanics before committing to implementation
- Unclear ownership communication in the early weeks of production
- Habit of committing to implementation before fully mapping technical requirements