top of page

Steamwell, Inc.

Role:
Mechanics Programmer
Software:
Unreal 5, C++

Welcome to Steamwell Inc., the future of steam technology.

​

As a guilt-ridden engineer responsible for the collapse of the Steamwell factory, you must venture back into the chaos to set things right. In Steamwell, Inc., navigate six dynamic levels and restore control by maneuvering pipes and machinery into place, solving spatial puzzles that challenge your pattern recognition, directional logic, and time management, all while outsmarting short-circuited security bots patrolling the factory floor.

​​

Core Mechanic Contributions

Push and Pull Physics Mechanic

Steamwell's pushing/pulling mechanic is the core mechanic of the gameplay. The mechanic is created through a raytracing function that selects the desired pipe. When the pipe is selected, the distance is recorded between the pipe and the player, and this distance is kept persistent as the player moves along with the pipe until the pipe is placed down again, allowing for multidirectional and smooth movement. 

ID-Based Puzzle Matching System

Steamwell's puzzle gameplay is controlled by an ID-based matching system that matches pipe placement areas with the correct pipe in order to confirm correct placement. Pipe System Managers are each given a specific ID and check a pipe;s ID once it was placed on a pipe manager.

Advanced Puzzle Development

With the previous mechanics put into place, I was able to extend the usage into puzzle mechanics like pattern recognition (chain of stored ID values) and spatial orientation challenges (rotating the pipe's changed ID values until the ID matched).

In-Depth Development Process

Concept and Design Goals

Our initial concept focused on an open-world narrative exploration game with elements of stealth and environmental storytelling. We began by prototyping a push/pull interaction mechanic that would allow players to uncover hidden elements of the world and progressively unlock puzzle components.

Motion-Capture Control System via Qualysis

The first hurdle in developing this experience was understanding the motion capture positioning in Unity space. After connecting Qualysis with Unity via the QTM ___, our team played around with positioning of the glove and how to send projectiles in the direction of the glove towards the player. We had two key takeaways:

  • We’d need some sort of hit box to prevent the player from simply keeping their gloves placed where the notes would land.

  • The note launchers would need to be positioned at a certain distance away from the player’s glove in order to reach the player in time for the music

  • Once the hitbox and launcher positions are finalized, they must remain the same for every player, no matter the height, arm length, etc.

​

Prototyping & Technical Challenges

We experimented with several implementations for object interaction, including:

  • Force-based interaction: Integrated naturally with the environment but lacked precision and control, making it unsuitable as a core mechanic.

  • Translation-based movement: Created smooth, player-relative movement but introduced challenges with overlapping, collision detection, and environmental feedback.

image.png
Screenshot 2025-07-21 005413.png
Finalized Interaction System

After evaluating the trade-offs, I developed a location-based movement system with the following features:

  • Maintains an offset between the player and object for consistent dragging behavior.

  • Dynamically switches collision modes:

    • During pickup: disables collisions with the player to prevent clipping.

    • During placement: re-enables physics interactions for proper puzzle logic and immersion

​

This solution provided the responsiveness, clarity, and realism we needed to support a puzzle-centric design.

Puzzle System Architecture

As the game evolved, we shifted focus to using object movement as a core puzzle-solving mechanic. This required a way to verify object placement and handle puzzle logic dynamically.

​

I designed a two-layer verification system:

  • Collision-based detection to recognize when an object enters a trigger zone.

  • ID-matching system to confirm the object type and its match with the puzzle goal.

​

This modular approach allowed for puzzle diversity without changing the underlying system, supporting:

  • Unique object models and materials,

  • Pattern- and orientation-based logic,

  • Expansion into more complex puzzle types without rewrites.

Scalability & Impact

Designing these systems to be modular made it easy to build out more complex puzzles without rewriting core logic. The ID-based structure worked well across different puzzle types, including:

​

  • Pattern recognition:
    Used a list to track each block placed by the player, then compared it to a target sequence. If the pattern didn’t match, the puzzle reset, creating a simple but reliable way to encourage thoughtful placement.

  • Spatial orientation:
    Each time a block was rotated, its ID value changed (incremented or decremented). This made it easy to track and validate whether a block was facing the correct direction, without needing to check raw rotation angles.

 

This setup kept the code clean, reusable, and easy to iterate on, letting us create new puzzle ideas quickly while still keeping everything consistent under the hood.

bottom of page