Independent Game R&D / 2026—Present
Driftlock
A clean-room, space-themed reimagining of a Flash-era pivot game, built around deterministic movement, reliable lock transfers, and a development process that remains playable one phase at a time.
I started this project after rediscovering XRaye, an old Miniclip Flash game I used to play. Its central idea still stood out: rotate a two-ended object around one point, release it, and catch another point to move through a level.
Revisiting it with more computer science experience made the rough edges easier to identify. Fast crossings could miss a point that looked valid, release motion did not always match the visible swing, and some collision rules were difficult to read. Instead of reproducing the original, I treated those problems as a research and systems-design exercise for an original game.
Driftlock is the result: a locking spacecraft that moves between stars, planets, and other orbital points. Phase 1 established trustworthy movement; Phase 2 uses that foundation for repeated objectives, moving asteroid hazards, a timed crossing, and a bypass-dependent final route.
01 / Rediscovery & Problem
A memorable mechanic with room to become more precise.
The project began with nostalgia, but the reason to build it came from separating what made the original compelling from the behavior that made it frustrating.
What was worth preserving
The two-ended pivot, immediate rotation control, deliberate release, and short routes between lock points create a compact mechanic with real timing and route-planning depth.
What felt unreliable
A free endpoint could visibly cross a peg without attaching, similar-looking releases could travel differently, and hazard boundaries did not always match what the artwork suggested.
A clean-room boundary
The original SWF is research evidence only. Driftlock uses original TypeScript, naming, visuals, audio direction, and future level layouts rather than publishing or porting the Flash game.
02 / Source Analysis
Turning remembered frustration into specific engineering problems.
Inspecting the compiled ActionScript behavior replaced speculation with concrete rules that could be tested and deliberately redesigned.
Sampled catches could tunnel
The original checked a small endpoint-and-peg bounding-box overlap once per 60 Hz frame. At maximum rotation, an endpoint could travel farther than the overlap window between samples.
Release blocked every catch
After detaching, the original disabled all peg attachment for roughly one third of a second. That prevented launch-point bounce, but it also ignored otherwise valid crossings anywhere else.
Launch direction ignored the swing
The recovered release rule used angular-speed signs and a fixed upward component instead of the tangent created by the current angle and attached endpoint.
Attachment changed momentum abruptly
A successful catch doubled angular velocity before normal friction. The remake keeps momentum changes explicit and bounded rather than hiding a sudden speed multiplier in the transfer.
03 / Product Direction
The new name, setting, and stack all support the same mechanic.
The concept became easier to reason about once the theme described the player's actions and the technology stayed small enough to keep the simulation visible.
Why Driftlock
The name combines the two essential states: the spacecraft drifts when free and locks onto stars or planets when an endpoint reaches a valid orbital point.
A space system, not a reskin
Stars replace pegs, asteroids can replace saws, and future planets or black holes can create readable gravity shifts. The theme gives new mechanics a coherent reason to exist.
A right-sized technical approach
Plain TypeScript owns the simulation, Canvas 2D renders the world, and React handles the surrounding controls and accessibility. A rigid-body engine would obscure rules that are simpler to model directly.
04 / Phase Plan
Build proof before building a campaign.
Each phase has a narrow exit criterion. The project only expands after the current mechanic is understandable, testable, and reliable.
Phase 0 — Research complete
Preserve the behavioral evidence, identify the real Flash-era rules, define the clean-room boundary, and turn the findings into an implementation plan.
Phase 1 — Physics lab complete
Prove attached rotation, tangential release, continuous lock detection, deterministic transfer, keyboard and touch input, and portrait-safe rendering in an isolated workbench.
Phase 2 — One playable level
Turn an original level sketch into multi-lock objectives, restart and completion states, local best time, moving irregular asteroid hazards, and a bypass-dependent goal on a separate route.
Phase 3 — Portfolio vertical slice
Create original artwork and audio, publish a tutorial and two challenge levels, and complete the loading, accessibility, and responsive product states.
Phase 4 — Expand from evidence
Add levels and systems in response to playtesting rather than committing to a large campaign, level editor, accounts, or leaderboards too early.
05 / Phase 1 Build
The first pass isolates simulation truth from presentation.
The lab is not a miniature finished game. It is a controlled environment for observing the mechanic, tuning its inputs, and proving its edge cases before they become level-design problems.
Explicit attached and free states
A discriminated TypeScript state model makes the current movement rule unambiguous. Endpoint positions are derived from the pivot, link length, and angle instead of drifting through an approximate constraint.
Fixed simulation, independent rendering
A 120 Hz fixed-step accumulator advances the same rules regardless of display refresh rate, while Canvas draws the authoritative state without deciding collisions.
Continuous and deterministic catches
Each endpoint's traveled segment is tested against capture circles. The earliest valid impact wins, followed by distance and a stable anchor ID when candidates are equivalent.
A real testing workbench
Live tuning, telemetry, collision geometry, pause and reset controls, accessible status text, and automated geometry and simulation tests make failures inspectable instead of anecdotal.
06 / Phase 1 Iteration
Small edge cases revealed where the rules still needed precision.
Once the main movement worked, focused playtesting exposed transfer and input cases that would have felt like clipping or randomness in a finished level.
Transfer continuity
A catch initially allowed the former pivot endpoint to shift as the ship rebuilt around the new star. The transfer now preserves that endpoint's exact pre-catch position, with a regression test comparing it before and after attachment.
Reversal without clipping
The previous anchor remains excluded while the free endpoint departs, but reversing before clearance makes it eligible again. The ship can relock on the original side instead of appearing on the far side of the star.
Bypass as one clear rule
Holding bypass now suppresses every automatic catch while leaving the current pivot and rotation untouched. Direction changes cannot override it, and catch detection resumes only after release.
Reliable held controls
Pointer capture keeps rotate and bypass holds active through normal finger movement, while non-selectable button labels prevent a long press from turning into browser text selection.
07 / Phase 2 — First Light
The mechanics now have a level that asks the player to understand them.
First Light translates an original hand-drawn route into a portrait-safe level with three distinct teaching beats and a complete retry-to-finish loop.
Repeated locks create the opening rhythm
Two-pip checkpoints must be caught twice. Moving forward, reversing, and returning teaches transfer behavior before the player reaches a hazard.
The crossing is a timing problem
Eight evenly phased asteroids wrap horizontally through the gap between two lock points. The wider off-screen loop makes each pass feel continuous while leaving a clearer opening for the full spacecraft to cross.
Visible shape and collision agree
Each asteroid uses a deterministic irregular polygon with its own profile and slow rotation. Full-ship capsule collision is tested against those same polygon edges instead of a hidden circular hitbox.
The fork gives bypass a purpose
Both branches are required and sit one link apart, but Zenith is only reachable from the fork. After visiting both sides, the player must hold bypass through either branch and release bypass near the center goal.
A separate level runtime owns progress
Lock counts, failure, completion, restart, and locally stored best time wrap the Phase 1 player simulation without changing its established movement rules.
08 / Play The Progression
Play the level, then inspect the lab it grew from.
First Light lives on its own Phase 2 route while the original physics lab remains available as a preserved checkpoint. Both versions make the project's progression visible instead of replacing the work that came before.