Laser Ball was an idea conceived after studying projects with kinetic interfaces. One example is a game created by college students, where a camera recognizes body motion and lines drawn with chalk, and can interpret such objects as barriers. Balls are then projected onto a chalkboard, which can bounce off of the human silhouette barrier and chalk lines drawn by the user. It is a very cool conceptual game, as it introduces many physical, foreign objects as the focal point of interaction. In addition to this game, I drew inspiration from the game “Line Rider”, which has the same notion of building modular barriers which another player can then ride. Like the first project, this game is about drawing lines that act as barriers, which the second player can “ride” on to escalate to the next level.
While these ideas were very cool, so too was this laser project by Graffiti Research Lab. In this colossal art installation, participants may use high powered lasers to draw on a building. Once again, a camera recognizes what the user draws, and a graffiti image is projected, in real time, onto the building. All of these project were cool, and inspired the idea of Laser Ball.
The initial idea behind Laser Ball is simple. Using a projector, I would project the image of balls drop from the ceiling onto an basket designated “Player 1” or “Player 2”. If a ball falls into the basket for Player 1, then Player 1 receives a point. The same is true for Player 2. Using lasers, both players would be able to draw boundaries that would be projected in real time, and affect how balls fall. Each boundary would cause any given fallen ball to bounce off of the boundary, which players could manipulate to their advantage. By using the laser to draw barriers, a player might guide falling balls into their basket.
The idea was simple enough, but difficult to implement. Although my first step was to discover how to draw barriers, Professor Moon’s advice guided me in the direction of getting the ball class to adhere to physics. For me, this was a learning process as I had only once worked with Processing’s PVector. Fortunately, there are many resources online that helped me get the basics of bouncing balls that reacted to one another. Once the balls bounced (against the sides and each other), it was a matter of creating the barriers. I had a bit of difficulty designing this, but with help I was able to create a barrier that the balls would respond to. I used this barrier to divide the bottom screen into two areas designated “Player 1” and “Player 2”. This way, falling balls would have to land in one section. Again, with help from the Professor, we managed to make this process much smoother, accurate, and efficient.
Here are some videos showing the ball’s physics development:
The next step was to integrate the lasers. Using a USB camera and color tracking code, we managed to have processing react to the laser dot and recognize it. What should be noted here is that each USB camera is different and provides different tolerances. In my process, I used 2 different USBs, and as a result, had to adjust the code with the help of the Professor due to the discrepancy. For future projects, I would recommend picking appropriate technology at the very beginning and sticking with those tools throughout.
Once the lasers were recognized, we crated barriers by making a new ball constructor within the ball class. This construct varied as it was white, would be drawn at variable intervals at the x,y position of the laser dot, and would fade, essentially dying after a second of existence. We added this mechanism so that the barriers would not last forever, and thus prevent players from permanently blocking their opponents side.
An issue arose once this was accomplished, as we noticed effects used to blur the image, such as blur() and dilate() functions, as well as the number of balls being drawn by the laser, adversely affected the frame rate, resulting in low fidelity. To remedy this, we projected the frame rate onto the screen and experimented by removing cam-distortion functions. In addition, I noticed that in a dark room sans ambient light, the projector light caused the USB camera to receive amounts of light comparable to the lasers, and would draw thousands of balls onto the screen. This was terrible for frame rate, resulting in some light necessary for the game to work.
Here are images of the final project’s set up:
After the basics were assembled, it was just a matter of fine tuning the game. Here are some videos displaying the game in its testing and final form.
First viable rendition: ki-final-doc1
For game testing view these videos:
This was a fun game and educational process designing it. It could not have been done without the help of Professor Moon, to whom I am quite grateful. I think that this game can be fine tuned and modified to make game play more interesting; currently, the natural stratagem players adopt is that of blocking their opponents goal. Were I to develop this game further, I would change the balls into various items, some good, some bad. For instance, maybe by adding “bombs” that would subtract points, players would try and block or push these object into their opponents area. Another idea would be to have the baskets or areas moving or dynamic, instead of static.
Still, the final product is fun and makes for a really cool lazer game.