Introduction and overview of the project

Kinetics is a team of 4 students from Entertainment Technology Centre, Carnegie Mellon University, which is dedicated to design, develop and implement SMALLab learn lessons/games to be used in 3rd to 8th grades so that educators can introduce/reinforce learning concepts in various subjects.

2 middle students from Elizabeth Forward School District is help the team with art assets and insights on how to make the game fit to the target demographics.

SMALLab (Situated Multimedia Art Learning Lab) is a mixed-reality learning environment, which uses motion-capture camera(s), short-throw projector(s) and wireless controller(s) to immerse players in dynamic game-based scenarios, where they can interact with each other and digital game elements in real time in shared physical space.

Game 1: Cupcake Wars Game
Concept we want to let kids practice: +-×÷Basic Measurement
Target demographics: 3rd ~ 5th graders

Game 2: Robot Programming Puzzle
Concept we want to emphasize: logical step by step thinking
Target demographics: 7th to 8th graders

 

The client of this project is Elizabeth Forward School District. They are transforming their district by technology with an emphasis on early STEM education by creating the most effective embodied learning experiences through SMALLab.

The instructors are Scott Stevens and Jessica Hammer.

What went well

1. Team role arrangement

We are a team full of programmer, which also means we are lack of certain roles in team, especially artists. On the same time, 4 programmers are too much for a small team like us. So the first problem we meet is how to arrange programming job. We have done a pretty good job at this.

First, we propose Aaron as a full-time producer, who also take responsibility for art-related works. For the other three of us, Fan takes care of customization tool which is a very important part for SMALLAB project; Allyn is the main programmer of gameplay; Michael studies SMALLAB related setting and API, and join Allyn’s work later.

This arrangement split everyone’s work as decoupling as possible, to make sure every programmer can utilize all his power while not interrupting others’ work. Our development pipeline proves that it’s a good decision.

After half, we have two games under development simultaneously. So we split the team again, let Michael take full charge of the first game, and other member of the team can focus on the second game.

2. SMALLAB

ETC installs SMALLAB at third flour, next door to our room. This really help us a lot. In Last semester, the SMALLAB team still need to write a “mouse version”, even a “PS Move version” to test locally, and can only test really SMALLAB every two weeks in playtest visiting.

Moreover, the SMALLAB installed at ETC is the new version of SMALLAB, which improve the racking quality a lot. The mistracking and instability problem is largely reduced in the newer version.

3. Focus on technology

Since we all a team of four programmer, we have a lot of potential in technology. As a result, we keep thing what we can do to add new technologies to SMALLAB.

In our second game, programming game, we propose an idea of adding a real robot in our game. After some research, we decide to use iRobot for its price and movement ability. However, although iRobot provide API for manual control, it’s really hard to develop a customized control program. Besides, how to connect between Unity and iRobot is a big problem. We overcome these challenges and add a full support of iRobot in SMALLAB.

We use Raspberry Pi as the middle part between Unity and iRobot using WIFI connection. We name it Robot Berry. First we send a command like “Forward” from Unity to Robot Berry. A standalone program written in Python is run on Robot Berry. Then, this program will translate the command to binary code for iRobot to recognize and send it. Then iRobot will following these code to do the movement.

The setting of iRobot in SMALLAB is very easy. One router, one Raspberry Pi, one portable charger and an iRobot is needed. We provide the possibility of adding iRobot as a part of standard SMALLAB setting.

4. Keep working

Last but not least, the major reason why we get a lot positive comment is that we keep working.

In quarter and middle feedback, our grade is actually very low, C+ and B correspondingly. But these grades didn’t stop us from working. Instead, we spend more time and think harder to make our games more pretty and fun. And these works give us an A- in soft.

Get a low grade at the beginning of semester is never a big problem. Every team has its own situation. Keep doing and doing, then everything will pay.

What could have been better

We should start talk to our target demographics earlier as we are much older than them and the elementary math education is very different between China and the States so we expected them to know things they haven’t learned from school.

Since we only get our iRobot create 2 delivered 1 week before soft, the development time for the second game is pretty limited. So, there are still many possible place we can improve on the second game.

First, we should create a calibration tool or a real-time feedback loop calibration for our second game to calibrate the iRobot according to the real size of the SMALLab. For now, we manually set the moving length and time of the iRobot which can take a lot of time and not very user-friendly.

Secondly, it would be hard for no-tech people to set up the iRobot and the connection may sometime lost during the game play. We can do experiment on more method to stabilize the connection if we got more time. Also, some old SMALLab system cannot open network connection while enable SMALLab tracking. We should consider another way of connecting iRobot such as Bluetooth and choose the connection type based on the machine.

Last, because due to the different material on the floor and different start position, the robot will have more or less offset during the game, which cannot be adjusted by now. We are thinking of attaching some tracking ball on the iRobot and dynamically check its position and rotation. Then adjust its next step base on its current status. It will be certainly improved if we got more time.

Lessons learned and conclusion

The first lesson we learned through this semester is thinking at player side. As an educational game, Cup war focus on practicing basic math skills. However, since we all from China and have accepted different primary education. The first iteration did not fit their current curriculum and was too difficult for our target demographic.

The second lesson we learned is the importance of playtest. Since most of us do not have designing background. The designing decisions we made first could be wrong. Therefore playtest comes to be standard of our design. During each iteration, we designed, implemented and did playtest on it. Base on the test result, and do it over again.

The third lesson is completion makes kids to explore more solutions. The beauty of game is it’s interactive. So as educational games. During the playtest, we found that the more competitive the game is, the more solutions kids explored. They learned and practiced through the competition.

Through the Robot + game. We also learned several different lessons.

In order to create embodied learning experiences, each element in the games should corresponds it. During the iterations of Robot +, we changed our UI design a lot and let every UI element to encourage embodied play.

For the space of customization, it is necessary design the game in an open space and leave that possibility of customization in every early stage. We also believe in the Robot +, we benefit a lot from the space of customization.

In conclusion, we learned a lot through this semester based on playtest result and feedback of faculties include design decision and several tiny lessons. In next steps, we are going to ship the game to our client with comprehensive documentation and customization tools.