The Clinical Problem
Proprioception is the sense of where your limb is without looking at it. After a stroke or similar neurological injury, it’s often one of the first things lost and one of the hardest to retrain; partly because the patient can’t see the deficit, and partly because the exercises that address it are repetitive to the point of abandonment.
Conventional proprioceptive training asks someone to hold a position, close their eyes, and estimate. It works. It is also almost impossible to keep a patient doing it for the number of repetitions that neuroplasticity requires.
That’s the gap this project addresses: the same clinical mechanism, delivered in a form people will actually complete.
Where Research Projects Usually Stop
Most academic software dies at grant end.
The prototypes work, the paper gets published, the funding closes, and the code sits on a drive because nobody built it to be maintained, deployed, certified, or handed to anyone else. It’s such a common outcome that it’s almost expected.
That was the explicit thing we were brought in to prevent. The project isn’t scoped as “build six prototypes”, it’s scoped as building six clinically valid games, testing them with real users, documenting them properly, and taking them along a path toward a commercialisable digital health product, with the regulatory and licensing questions raised early rather than discovered late.
Our part of that is the engineering and design half: turning what the clinicians know into something that runs, and keeping it buildable after we’ve gone.
Building a Difficulty System Out of a Clinical Taxonomy
The intellectual core of the project is a framework the research team developed: a Proprioceptive Sensory Taxonomy that describes rehabilitation difficulty along five independent axes.
- Sensory function: from static position sense, through kinesthesia and force sense, to full multi-sensory integration.
- Sensory dependency: from full visual support, through reduced cues, to no vision at all, and finally to deliberately conflicting visual information.
- Spatial precision: from wide targets to high-precision targets to blind targeting.
- Temporal load: from a static hold, through slow and rhythmic movement, to reacting to unexpected change.
- Cognitive load: from a single task, through dual tasks and divided attention, to problem-solving under load.
A level in the finished system is a coordinate: one value on each axis. A1 D1 S1 T1 C1 is a first session. A4 D4 S4 T4 C4 is someone close to discharge.
For a developer, this is the most useful thing a clinical partner can hand you. It converts “make it harder”, the vaguest instruction in serious games, into five parameters a therapist can tune independently. Difficulty stops being a designer’s guess and becomes a clinical decision, made by the clinician, for a specific patient.
Everything we build against that framework is parameterised, so the taxonomy isn’t a document that informed the design. It’s the design.
The Constraint We Reported Rather Than Hid
The taxonomy includes a force sense step. On a standard touchscreen, actual physical force cannot be measured, and no haptic resistance can be delivered. The hardware simply doesn’t allow it.
We said so, in writing, rather than shipping something that implied otherwise. For the 2D builds, that axis is adapted explicitly into a visual-spatial force perception construct, tension represented by how far the patient drags back across the screen, and documented as a different thing from what the VR builds can offer.
It’s a small point that says most of what matters about working on clinical software. A serious game that quietly misrepresents what it’s measuring isn’t a shortcut, it’s a defect and in a research context it contaminates the data the whole project exists to produce.
Six Games, Two Formats
Three VR builds and three 2D builds, most grounded in ordinary daily tasks; stacking shelves, shopping, parking a car, cleaning, using a lift, catching fish because activities of daily living are what rehabilitation is ultimately for, and a task a patient recognises transfers better than an abstract one.
The two formats aren’t duplicates. VR delivers genuine spatial demand and full visual occlusion, and is the right instrument for the upper reaches of the taxonomy. 2D runs on a tablet a clinic already owns, or at home between sessions, and reaches patients for whom a headset isn’t appropriate. More on how we approach VR and XR generally.
Accessibility and personalisation are built as their own modules rather than as options bolted on: visual cue systems, adjustable control mechanisms, and per-patient level planning. The target user may have limited range of motion, reduced attention, and post-stroke fatigue and that’s the baseline case, not an edge case.
The Workshop Rhythm
We run regular workshops with the faculty team throughout development, academics in rehabilitation, graduate researchers, and physiotherapists; reviewing scenarios, validating in-game mechanics, and testing builds.
Then pilot testing with physiotherapists and real users, structured feedback forms, and revision passes driven by what comes back.
This rhythm is the whole reason the project will produce something usable. Clinical intent doesn’t survive a document handoff. It survives a clinician playing the build and saying no, that’s not the movement. We’d rather hear that in week seven than read it in a final report. It’s the same principle behind the pedagogy workshops in our educational game work, applied to a field with stricter consequences.
Where It’s Heading
The project’s stated aim is a commercialisable digital health product, which means the questions that usually arrive too late; regulatory compliance, CE marking, licensing models, dissemination are on the table during development, alongside technical documentation and user guides written for people who aren’t us.
To be clear about status: the games are in production and in testing. Clinical outcomes are for the research team to establish and publish. We build the instrument; the evidence is theirs.
What We’d Bring to Your Project
- Turn the framework into parameters. If your research has a model, it can become a difficulty system that clinicians control directly. That’s the single highest-value translation step in a project like this.
- Report the constraints. Where the hardware can’t deliver a construct, say so and adapt it explicitly. Silence contaminates the data.
- Build the review rhythm in. Workshops and pilot testing on a schedule, not at the end.
- Design for life after the grant. Documentation, maintainability and the regulatory path from week one, or you’ll have prototypes instead of a product.
Work With Us
If you’re running a funded research project, TÜBİTAK, an EU framework, a university programme, and the deliverable is software that has to actually work, this is the specific thing we’re good at: taking a clinical or pedagogical model from the people who developed it and turning it into something that runs, gets tested, and outlives the funding period.
We’ve done it with a national ministry and the Council of Europe, with METU under COST, and now with Hacettepe University under TÜBİTAK. More on educational and serious game development, or how a project runs with us from scoping through handover.
If you’re mid-application and need scope and budget figures for a proposal, we’ll provide those too.
Got a Game That Needs to Ship?
Send a design doc, a build, or three sentences and a reference game. We’ll come back with scope, team and a number.
