Quest-to-Learn teachers, Limor Levy and Andrea Henkel were leading the “tinkering” part of the boss level (12/06/13) and interested in having a digital simulation of the tinkering experience in SMALLab. She showed me a web game called Tinker Ball as a reference to what they had in mind. The game was made by Lemelson Center for the study of invention and innovation. In Tinker Ball, the player has to build a contraption to guide a little ball into a randomly placed bucket at the bottom of the screen. This is a potentially effective learning mechanism – theory building and iterative process – if bundled with properly design supporting lesson plans.
My biggest dissatisfaction from a game developer’s point of view is the poorly integrated physic simulation. The physic interactions between the ball and all the tools are far off from the reality that they stop learning moments from stimulating. I immediately accepted the proposal and took on the challenge to develop this new SMALLab game in two weeks. I’ve recently tested out a new development pipeline to build games and it involves a physic engine, so this project came at the perfect timing! SMALLab hasn’t had any game using a physic engine before because the concept of gravity might be confusing on a floor projection. Now is the time to find out.
The new SMALLab game is designed to have two phases. They are the tinkering phase and simulation phase. Players will be going back and forth between the two phases to improve their contraption until the ball successfully falls into the goal bucket in the simulation phase. In terms of game control, some of the objects in this game require angle adjustment and it’s challenging to have two separate control states – position and rotation, on a buttonless SMALLab controller. After a few testings, I decided to have those objects start rotating on itself once the player picks it up and stops rotating after the player drops it off. This way, the player only has to worry about one thing at a time. During the testing, I thought of making use of the rotation data from Optitrack. However, because I am developing this game remotely, I decided to save this task for later.
After sent in the first prototype and discussed with Limor over the e-mail, I realized what she envisioned was more complicated than Tinker Ball or maybe her imagination had grown since last time we talked. It has become more like a Rube Goldberg machine builder. The first time I saw a Rube Goldberg machine was in an old Jackie Chan movie called “Drunken Fist”. My most recent trendsetting experience with Rube Goldberg machine was by Shogakukan’s Pitagora switch (ピタゴラ装置) on YouTube. At first, I was worried the current prototype is lacking the defining element of a Rube Goldberg machine – the chain reaction. Tinker Ball type of game reminds me more of LEGO’s Great Ball Contraptions (GBC) or games like “Screwball Scramble” than Rube Goldberg machines. I thought that a Rube Goldberg machine focuses on triggering different contraptions with various types of energies like the game “Mouse Trap”. However, after researched further, I was convinced that creating a modular contraption to guide the same ball to a goal bucket is a type of Rube Goldberg machine.
I finished coding the game early and decided to work on the visual of the game before the SMALLab testing and rehearsal which is the week before the boss level. The visual presentation of the game is one of the many elements I utilize to build engaging play experiences and it is often inspired by the overarching theme of the semester. However, the upcoming boss level doesn’t have a theme to follow so I came up with my own look & feel – creamy pastel colors and wallpaper patterns. Because of Pitagora switch videos, I was determined that this game needs a Xylophone background music. Iva made me the perfect one in minutes with her music composing magic.
Limor and Andrea designed an amazing excise for students prior to the SMALLab experience. They made a paper version of the game and have the 6th graders cut and paste the paper tool pieces into a design that they imagine would take the ball to the goal bucket. This is done a day before SMALLab. Till this point, they have not seen how each tool actually behaves in matchbox tinker so they have to come up with their own theories around each tool. The result of this exercise is an amazing collection of creative solutions to one single problem – ball in the bucket. This preparation built up such a fun and engaging need-to-know for students to want to find out if their own crafty design actually works out in the digital simulation.
The day has come, anticipating students surround the white mat with their own design in hand and eyes on the glowing projection in the dark SMALLab room. We ran the usual schedule, 8 home bases in one day, and that is about 120 students in 4 consecutive 45-minute sessions with breaks in between. After Andrea explained the game to students, we ran the first simulation. I heard a student yelled out and I continued to hear it many times throughout the day in different sessions, “This ball is so bouncy!” They noticed the differences in behaviors between their imaginary ball and the ball in the game. Many of them also realized the dryers are stronger blowers than what they had originally imagined in their paper prototypes. By the way, gravity on the floor wasn’t a problem at all!
I noticed an interesting embodiment piece that some students had difficulties getting the angle they want when placing the tool down in the workspace. This is their 2nd time in SMALLab and not very good at working with their body in the space yet. In order to get the right angle, the player has to predict the rotation and side out the controller early to cover up the delay caused by the hand motion. This requires good eye-hand coordination and it was definitely a challenge for some students.
“Let’s just build a tunnel for a ball to go down!” and this happened…
The ultimate next step is to have the working contraptions printed out from a 3D printer so the students can see their own creations in action in the real physic space. This will bring the learning home and to the next level. It rounds up the play experience in full cycle with paper prototypes, digital simulations, iterative designs, and real working products.
12/03/13 Basic build is finished, sent an e-mail to Limor for more ideas for artifacts that are relevant to the boss level players. If spacebar is pressed (drop a ball) while dragging, makebody() of the dragging artifact will not run therefore ball goes right through.
12/12/13 Update to Ver.2 for the desktop application, change the control to mouse-friendly.
12/16/13 Major slowdown on gameplay when first tested on the SMALLab computer because all the PNGs used in the game. Switched to OPENGL in 1.5.1 solved the problem.
12/17/13 When the controller lost tracking while carrying a tool, it takes the tool to (0,0). When this happens to a cog, it simply disappears and left with a small pink circle at (0,0). Solved by repositioning all the tools that land on (0,y).
“Where is the ball?” heard that a lot during their first building phase.
When two objects collide, they also make the ball impact sound.