Birdy: Full Documentation

There was one thing I knew that I wanted my final project to be the moment I started thinking about it: I wanted it to be cute. Other things I knew were a) I wanted the project to be processing heavy, while physical computing light, and b) to be a game. I really wanted to practice coding more, and I also particularly enjoyed the week in class when we had made a game (I made “Blobby”).

After more in-depth brainstorming, and class suggestions, I came up with the following idea for a game: the user would be a bird, and by flapping his/her wings, would fly the bird around various environments. Games would be hidden/placed around the environments, and the bird could go around playing those games. Later, I fleshed out the idea further: the bird had to play the games in order to earn “seeds” (points) to feed her babies that were to hatch soon. Once the bird reached a certain amount of seeds, the game would end, the user would win, and the babies would hatch and fly happily around with the mother bird on the screen.

The process of making the game looked like this:

a) Planning: I had to plan all the various games, decide what types of visuals they would need, and think about how to convey all the instructions of the game to the user. It was critical that I do this to avoid wasting time in the next steps.

b) Design via Illustrator: I spent many many hours before even starting the code creating all the visual elements of the games. I created the bird(s) myself in Illustrator (making various frames so the bird would look like it was flapping its wings), found various free Illustrator elements online that I would then have to adapt quite a lot to fit my vision, and had to make multiple versions of everything to create the blinking or movement effects that I wanted. Overall, this was extremely time-consuming (especially since I had to redo quite a lot of it later since I had to make sure all the sizes of the files were consistent and appropriate for Processing), but it was a crucial step since the visual aspect of the game was important for it to be successful.

[Below are just a few of the Illustrator elements I created or edited.]


c) Coding: The coding aspect of the project was undoubtedly the hardest part of the project. Not only did I have to create the code for five different minigames, but I had to create the code for the overarching/big picture aspects of the game. These include things like: how, and how long, to display instructions, where to start and end the game, how to let the user find different games, whether the user can play each game more than once or not, how to let the user move from one environment to the next, whether the user should be allowed to move to another game without finishing the first game or not, and on and on. I didn’t realize how complicated this process was going to be until I was rather far along in the project, when I started to appreciate the way that the seemingly unimportant questions in a game (like the issues I just specified) actually make or break it completely. However, one thing I am very proud of and would like to note is the following: I did know that, at the very least, the code was going to be rather lengthy, and thus I spoke with a computer science friend who helped me map out the plan for the code. It was through this that I got the following idea: instead of making completely different code for each minigame, I could use classes to sort of reuse the same code over and over, adapting it for each game. This made perfect sense for my game, since in each game there is an “other” (whether it is a coconut, a fish, etc.) and in each one some sort of overlap needs to be detected. Thus, I utilized classes to my advantage in the code, and believe that as a result the code is far more simple/clean/short than it would have been otherwise. This experience demonstrated to me that planning before coding is crucial to avoid headaches and wasted time.

[The Processing code for the game can be found here, and the Arduino code can be found here.]

c) Physical computing: The physical aspect of the game actually turned out to be rather straightforward and reliable — which is something I cannot say about most of my experiences with sensors in the class. I used an accelerometer, which measures (as the name suggests) acceleration/the rate of movement. I wanted to use it to measure the user’s flapping, so it was perfect because the user truly had to flap to make the bird on the screen move; if they moved really slowly would not work. All I really needed to do was detect the x, y, and z coordinate from the accelerometer and measured the difference between that reading and the previous reading (to see if the user was flapping). I found an equation to calculate this online: sqrt[(x2 – x1)^2 + (y2 – y1)^2 + (z2 – z1)^2]. In regard to how I used the accelerometer exactly, what I did was this: I soldered each (of the two) accelerometers to six feet long cables, which were plugged in to the Arduino/bus board. (Each accelerometer needed six cables, so that means I soldered 12 six-feet long cables in total.) Then, I hid the bus board / Arduino in a pretty box, covered cables in pretty, flowery tape, zip-tied the ends of the accelerometers to a pair of black gloves, and then hot-glued tons of pink feathers onto the gloves. Overall, I very happy with how it all looked: the green/pink theme of the box/cables/gloves fit perfectly with the green/pink theme on the screen.

[Below are pictures of the end product. Note how in the picture on the left, Craig’s pink wig makes an appearance.]

The IM Show:

I was really happy with how the game was received at the IM show — especially when a girl came to play the game, lost the first time, asked to play again, then won, and then jumped up and down out of excitement, took a picture of the winning screen, and then gave me a hug. 😛 While not everybody was as excited as she was, a lot of people found the game really cute, rather fun (particularly because of the wings/gloves), and overall a nice idea. I do, however, think that it might not have been the best suited interaction for the show, since the game is rather long if it is played all the way through, and most people want to only spend a short time at each interaction so that they can get through all of them. This means that a lot of people would stop playing part way through the game. In the end, still, most people seemed to really like it, and I was incredibly happy to share the game with others.

[Here is are two extra photos, one of Luize posing after playing the game and winning the high score, and another of the feathers that were sacrificed during the IM show.]