Each quarter, Helios team members are invited to participate in an internal study. These studies challenge our developers and designers to work outside their comfort zones creating innovative solutions for common client problems using technologies they might not be familiar with. By participating in these studies, our team members expand their skill sets and develop new experiences we can offer to our clients. The subject of our second internal study, The Warbler, was our take on the hoverboard. This futuristic skateboard would require our creative developers and designers to work with external sensors and produce unique and exciting experiences using physical computing.
The Warbler project began when Helios interactive developer Gonzalo Eyzaguirre created a server that could read data coming from a variety of sensors and plug that data into Unity or web applications using OSC or WebSockets. This helped team members become more comfortable with physical computing and begin thinking of ways they could incorporate real-world objects into upcoming brainstorm sessions and client projects.
Our team members made a variety of projects using the Warbler, ranging from Unity VR games, a web-based graphics controller, an ’80s-style flight simulator, and immersive auditory experiences. Some developers added additional physical components to their projects, such as a re-purposed elliptical trainer and handheld Vive controllers, while others kept their projects more singularly focused. We ended up with seven original applications:
- Toobin, a VR river float experience;
- Warbler Rash, a race-against-time snowboarding game;
- WaT ~ ワーラー · ターンテーブル ~, a high-energy combo of music and generative graphics;
- Labryinth, a frustratingly difficult game of balance;
- Tippecanoe and Dabber Too, a goofy VR rhythm game;
- Glide, a futuristic obstacle course;
- Roll & Bowl, a time-bending multi-layer bowling game
While not all projects behaved exactly as their creators intended them to, the overall experience of working with physical computing and real-world objects was very positive. We learned a lot about what makes a physical computing app work well (not too many external distractions, incorporate a lot of sound and visual rewards, etc.) and what causes a bad user experience (turns out strapping someone into a VR headset and putting them on a hoverboard is not such a great idea). Most importantly, our team members learned the valuable skill of taking sensor input data and using it in a variety of ways. In the future, we’ll be able to quickly and easily add any number of sensors to objects and use their data without having to reinvent the wheel for every physical computing project.
Interested in learning more about our work with physical computing or our upcoming internal studies? Drop us a line at email@example.com.