[Edit: Go to bottom to read additions.]
“US Catch & Snatch” is an in progress game that I’m working on for my Intermedia course. I came up with the idea following the international news that the United States has taken into custody Ukraine’s gold to protect it in the United States treasury. Meanwhile, other headline news reported Ukraine’s gold as missing, or mysteriously taken. According to some sources the same has happened to other various countries that have been involved with the United States in some capacity. I found it exceedingly interesting that an airplane would seize and take hold of another country’s currency for the sake of protecting it in another country, and that not all opinions on the matter would see the event in the same light. It is my desire by creating this game to provide a new angle to the subject through parody and simulation.
The assignment for this project was to follow a tutorial, and using a sensor, animate the tutorial in processing. I got a little ahead of myself on this project and tried various times to edit rather complex (for me) codes in order to take a Raindrop game, and input my own sprites as images (using creative commons sprites). This proved more challenging than anticipated due to the location of the “catcher” and “drops” being variously tied to their radius. Meaning if I removed the radius because the new cursor no longer needed one, then I would screw up the rest of the formula used to run the program. My best guess for resolving this issue would be to leave the original commands, and write a sub draw area that would upload my images and continually draw them so that they cover up the old icons, which would still run. I could also try to upload the images so they are seen as ellipse shapes, but I don’t know if it would recognize radiuses the same way as it does for an ellipse in the program.
While I’m going to go back and work on that, in the mean time I decided to find a simpler sketch to work off of for the tutorial assignment. This time I modified an “etch-a-sketch” tutorial, so that the X input of my “catcher” would be determined from a potentiometer hooked up to the arduino. This tutorial was by far the easiest to follow, understand, and cut apart to fit my needs.
Above: Image of processing program. Airplane graphic has a fixed Y location, and X location changes depending on the potentiameter. The airplane will be a “catcher” and will collect falling objects by moving left and right on the screen.
Above: Modified raindrop game. I was able to change the speed, size, and color of the falling objects and catcher, but I could not replace them with a new external image. The white circle in this case is the catcher that I would eventually like to replace with the airplane, and the yellow circles I would like to replace with coins.
I will update more on the development of this project, and at the least, with videos of how the program runs.
So after yesterdays problems, I decided to leave the r values, and find a way to animate on top of them while they were moving through space in the program. I recalled that anything written lower in the code covers up what comes before it, so I could just draw on top of it and hope that it wouldn’t lag too much. This was actually much easier than I anticipated. All I had to do was move the image over and up a little for the x and y axis, and tweak the size. For some reason there were a bunch of i values which wanted to cone the shape into a teardrop (it makes sense considering the origins of the file), so I just deactivated them and left them in the text for now.
Now the only requirement left would be to find a way to move the x axis by using serial port information from the arduino. I may have a hard time with that since the game code is so cluttered it is hard to find a good/proper spot to do anything. Once I get that done though it would be nice to add some sort of counter which keeps track of how many coins were caught.
Getting the arduino to talk to the program wasn’t as hard as I anticipated. I used my simpler program first to figure out where everything should go in the program, then copied it over to the “sloppier” code. Now that I’ve gotten more familiar with how the codes are written, I’m figuring out that the codes aren’t as cluttered as I thought they were at first. They are actually pretty straight forward and easy to tweak.
I found an edit for the raindrop game that added levels and a score, but when I changed my program to have the additions it would crash the program each time the coins would intersect with the airplane. I think it became too much to render instantaneously within processing. I may find another way to make a counter, or I might just find a way to formally tackle the counter in another piece.