Case study · Game design & engineering
Tenzr game platform
Rehab exercises are repetitive and easy to quit. I designed and shipped three motion-controlled games on a shared engine I built myself. This case study focuses on Stellar, the flagship title, where playing and exercising are the same action.
Current build · Full gameplay recording
Designing for adherence
Patients using Tenzr wear a sensor that tracks wrist movement, the same movement their therapist prescribes as exercise. The design challenge was making that movement feel like play, not a repetition count. I designed obstacle patterns that required moving through the patient's full prescribed range, so progressing in the game and completing the exercise were literally the same action. There was no way to "win" without doing the movement correctly.
The first version ran on Xamarin on top of a game engine I wrote from scratch. I structured it around the object lifecycle I already knew from Unity, where each object updates and renders independently during every frame.
Movement-driven patterns
I designed obstacle formations that required the player to move from one side of the available range to the other. The challenge came from reading and completing the movement pattern.
The video below shows that first version in action, and the images that follow show the obstacle patterns, the movement range they were built around, and the game running inside the patient app.
Original build · Xamarin and custom engine · Full gameplay recording
Moving to MAUI
Xamarin's deprecation forced a platform-wide move to .NET MAUI without disrupting gameplay for existing patients. The rebuild also had to support phones in portrait, not just tablets in landscape, doubling the layouts the game needed to handle. MAUI offered a direct equivalent to my original rendering approach, but adapting it for the new orientation required comparable effort to rebuilding on a dedicated engine. I chose Orbit for its object lifecycle, which matched my original design and let me port the obstacle logic and movement-mapping systems rather than rewrite them.
A parallel redesign
When Tenzr brought on a new design team, we used the moment to fix a mechanic that wasn't working. Every 10 coins collected granted the player a temporary shield, but the game also displayed a running coin count next to a distance counter. Players couldn't tell which one was actually their score. We removed coins entirely and kept the core obstacle-dodging loop. We didn't track this formally, but the team heard fewer reports of players being confused about scoring after the change.
We also moved the ship off its original red, which read more like a warning colour than a player character, and brought it in line with Tenzr's platform palette instead. The comparison below shows both versions side by side, the original design and the redesign that followed later.
Building on Orbit
I adapted Orbit with the same per-object render, update, and collision lifecycle I used in the original engine. I added a data-driven spawn and phase system so new obstacles, formations, and hazards could be introduced without rewriting the core loop. The three stills below show that system producing different obstacle types from the same underlying rules: a debris pattern, space ships, and bouncing asteroids.
Outcome
Since the MAUI rebuild, the games have recorded 3,000+ completed play submissions from patients doing their prescribed exercises through gameplay rather than a rep counter.
What I'd take from it
Designing the game mechanic and the exercise as the same action, rather than treating motivation as separate from the exercise itself, is the part of this I would carry into any future health or behaviour-change product. It also shaped how I approach technical rebuilds. A rebuild is not always the more effective path. Sometimes the better move is picking a new tool that fits how you already think, rather than assuming a full rebuild is the safer choice.