Project SANDBOX was an iterative 4 month Spring 2014 initiative at the Carnegie Mellon University Entertainment Technology Center (ETC) tasked with bridging the gap between young children, their families, science content, and maker culture.
Together with the New York Hall of Science and the Children’s Museum of Pittsburgh, SANDBOX created a digital experience that encouraged play, exploration and collaboration between parent and child.
Very early on, we discovered Sifteo Cubes, and were awed by it's intuitiveness to both children and adults. We did 2 prototype games to specifically test this ease of usability, and playtested these prototypes with children and adults at Children's Museum of Pittsburgh.
We soon found sure footing with the Cubes when we came up with something very similar to Kerbal Space Program, and everyone was very excited by the prospect of building rockets like LEGOs.
We ran with the idea the rest of the way, and have received incredible feedback both from the New York Hall of Science, and from the people we watched play the game.
As the programmer on the project, my contributions were:
- Tech recon: Figure out what works for our mission, and pitch it to the team
- Sifteo Cube development on the Sifteo SDK (C++)
- NodeJS websocket server to channel data between Unity3D and the Sifteo Cubes (JavaScript/CoffeeScript)
- Editor tools in Unity to facilitate tweaking game parameters for non-programmers (C#).
- Rocket builder: Build the rocket in Unity based on current state information from Sifteo Cubes.
- Prototyping shaders for cool effects (atmospheric friction, etc) (HLSL).
Some interesting challenges that I encountered over the course of the project:
- Bandwidth: Sifteo cubes had a limited bandwidth to communicate over USB (60 bytes), and the state information we needed to send clocked at around twice that amount. I ended up writing routines to pack the data into 36 bytes, by defining ranges for each type of data that I needed to send, and making sure they got exactly as many bits as needed, and not a single one more.
- Fault-tolerance: The Unity plugin I used for Websocket communications, as well as the USB library for NodeJS, were not very mature, and failed often. I tried doing a lot of interesting (and to me, at the time clever) things to fix it, but in the end the most reliable method was a simple master-slave program pair where a master process simply watches the communication script, and relaunches it if it fails.