Solid Game is an HTC Vive / Unity prototype built to explain privacy-preserving VR telemetry. A user interacts with simple objects in VR while the system captures interaction data and demonstrates raw versus encrypted/privacy-preserving analytics output.
The project was created as part of a Master’s thesis defense on secure frameworks for user motion data in virtual reality.
VR systems collect rich behavioral telemetry. Even simple interaction data can include repeated patterns in timing, movement, reach, and controller behavior. This creates a difficult tradeoff:
- researchers and developers need analytics to improve XR systems;
- users need privacy, consent, and protection from identity leakage;
- abstract encryption/privacy concepts are hard to explain without a concrete interaction.
Solid Game was built to make that tradeoff visible.
How can a VR demo show the value of privacy-preserving telemetry without overwhelming the audience with cryptography details?
I designed the demo around a deliberately simple interaction: the user manipulates three spheres in VR. This keeps the audience focused on the telemetry pipeline instead of game complexity.
The interaction flow is:
- User enters the VR scene.
- User interacts with three spheres using the HTC Vive controller.
- The system logs motion and interaction telemetry.
- The demo compares raw telemetry with encrypted/privacy-preserving analytics output.
- The audience sees why privacy protection matters even in a small VR task.
- Unity
2022.3.5f1 - C#
- HTC Vive
- SteamVR SDK
- Custom telemetry logging
- Homomorphic-encryption-inspired secure analytics demonstration
The prototype avoids complex game mechanics because the core thesis is about telemetry privacy. A simple scene makes the privacy pipeline easier to understand.
Raw versus encrypted output gives the audience a concrete mental model. Instead of treating privacy as a policy claim, the demo shows a before/after analytics pathway.
VR privacy is not abstract. It comes from body movement, behavior, and repeated interaction patterns. Using an actual headset/controller demo makes that risk easier to communicate.
The project depends on HTC Vive and SteamVR. That makes it stronger as a real XR artifact, but harder to run casually. The README therefore needs strong media and screenshots.
The prototype demonstrates secure analytics concepts, but it should not be presented as a production privacy library. The documentation frames it as thesis proof-of-concept work.
The project sits between academic research and runnable Unity code. The strongest presentation is a case study that clearly links problem → prototype → thesis contribution.
- Unity VR prototyping with physical headset/controller interaction.
- Ability to build research demos that explain complex technical ideas.
- Privacy-aware thinking about XR telemetry and behavioral data.
- Communication skill: turning thesis work into a visible project artifact.
- Add exact scene and SteamVR setup instructions.
- Add annotated screenshots of raw/encrypted telemetry output.
- Extract reusable telemetry components where possible.
- Add architecture diagram: interaction → logger → secure analytics → visualization.
- Link this demo to the broader private XR telemetry pipeline.