Final Documentation: Color Fall


After the tragic failure of my midterm project, I was determined to build something less physical and a lot more coding based. I wanted to overcome my fear of coding to create something meaningful. I then remembered one of the in-class projects I had not completed – a simple game for which I had given up coding all of its components. For my final project, I promised myself I would complete this game.


The game was heavily inspired by one of the online games I used to play when I was younger, where I had to control a player to stay along lines that were infinitely generated from the bottom of the scrolling screen. Each line was gapped, and the goal of the game was to guide the player through the gaps to stay at the bottom. The game was over when the player hit the top of the screen. I wanted to recreate this game, but this time with much more interaction and engagement. Instead of a virtual character controlled using just arrow keys or joysticks, I wanted the character to be more tangible to the players; so I decided to use the motion of real balls to control the position of the ball character. Furthermore, I wanted there to be more dynamics other than simple left/right controls, so I implemented different colors as part of the control. I decided to use two features – real-time position tracking and color tracking.



Final Code

Game Screens

Color tracker

Scrolling Lines Class


Progress, Problems and Solutions:

Initially, I only had made the class for lines that scroll up the screen – no randomly generated gaps, no balls, nothing. It did not help that I didn’t know anything about coding, so I didn’t know where to start. I had the habit of setting every variable as global without realizing its effects – which was one of the first main problems I had with my code, because no line of code worked as expected!

I learned about calling variables within classes which allowed me to generate gaps. Now I had to make them random, as well as implementing random colors. This came back to the problem of having many global variables because it somehow canceled the effect of random generation. It took me a while to rearrange the variables appropriately.

Finally, having different games screens to improve the overall aesthetics of the game meant that I had to rewrite my entire code. Because I didn’t think about having game screens from the beginning, my code was a mess. I was afraid to change this at first in fear of messing up everything (which did happen), but I eventually managed to reorganize it. I referred to this helpful tutorial on making game screens to guide me through.

Coding progress – Save As is key!

Initially I thought of making a device using Arduino and physical sensors to detect each color and position of the plastic balls – options included RGB color sensor and ultrasonic sensor/force sensor – but after experimenting with them, I realized they were much less reliable than I expected. I changed my plan of using physical sensors and diverted towards image processing instead, which allowed detection of both color and position at the same time. I modified Daniel Shiffman’s Color Tracker to detect 4 plastic balls of different color.

The final problem turned out to be the detection of colors themselves. The color tracker was built to only track preset RGB colors coded prior to running the program, I had to recalibrate all colors using an online tool every time ambient lighting slightly changed. Furthermore, I didn’t realize until the day of the show that because the webcam autofocuses itself, the colors under the same lighting can fluctuate. On top of that, the lighting during the show produced shadows over the play area, which also affected the performance of position detection of the balls. I think this could have been much more improved by using HSB (hue, saturation, brightness) that Jack told me about (unfortunately, on the day of the show) instead of RGB.

Colors in IM Lab vs Showroom
Apparently, they are completely different colors…

Show and Reflection:

I aimed to make my game as self-explanatory as possible – i.e., no signifiers. The game was entirely controlled using detection of the plastic balls, without other means like switches/joystick, so the players had to figure out how to start the game using just the balls. Overall, whereas the controls and the goal of the game itself seemed to be communicated well to most people, they struggled to actually play the game due to the problems with color tracker listed above. Throughout the show, I mainly had to demonstrate how to play to minimize the effect of color fluctuation. Other than that, I feel my game was overall very well received – the game was simple enough that the players became engaged easily and fast.

Leave a Reply

Your email address will not be published. Required fields are marked *