Final Project simplification and reorientation

Well, I was hammering out a specific schedule for my final project, and I came to the conclusion that I needed to greatly simplify my plan to allow for completion with a little extra time for tweaking and bug fixing. With getting the Arduino to communicate multiple data pieces to Game Maker, polishing the game (user interface, game objects), completing the game art, acquiring and building the controller, this project would not be completed by the time, and even if it was, it would not be polished enough to be proud of.

So I’m planning on doing something similar (building an unorthodox controller for a game I create) but simplified enough so that it can still present artistic, technical, and conceptual work, but not be so large that it can’t be completed and polished by the due date.

I actually came upon this option earlier while researching how to get Arduino to sync with Game Maker. I asked around on the internet, forums and the like, to see how anyone had solved similar problems, and one of the people I asked was very helpful and gave me two options for communication with Game Maker. One of those options I really started to get excited about the concept, and the site is here: http://www.makeymakey.com/

Makey Makey is a keyboard and mouse interface developed by two students from MIT that allows designers to, basically, use anything as a keyboard. It’s quite amazing, as the demo video, with real working examples, shows. In the end, pretty much anything can be used to transmit a signal: food, stairs, water buckets, even other people. Just hook up the object to the Makey circuit using an alligator clip or regular wire, and that object is a key. So how does this relate to my earlier project?

Well, this piece will have a performance aspect, in addition to the game and controller that anyone can play. Really thought, this game will not have a specific “win” condition, only a continual evolution of image, so it could be called a toy, that doubles as art. The toy will be simplified in purpose, and also execution, so that anyone can come along, and for even a few seconds, play with it, then leave if they want with no ill effects on the overall image. Objects can be moved on screen and interact with each other, but while no one is playing, it will sit there as generative art, in a sense. Each player contributes to the image on the screen. I also feel this “come and go” aspect will be more engaging for exhibition goers than a game with a definite beginning, end, winning/losing, and rules to learn. There will be rules to this piece as well, but only in the form of moving up/down/left/right, and choosing an object to move. When objects on screen touch, they will react in beautiful ways, producing more art objects to interact with, and so on. This simplicity should draw more people into the process of creating the image, and enjoying themselves while creating art.

So, what about the physical aspect of this, you ask? Well, in order to create the art, the artist/exhibition goer will first need to hook up the “keys” to the controller. I like the idea of using food for the keys, because since food is essential for life, now food will be essential for art, particularly this art. Players will choose what objects to use for each key based on their personal preference (a fruit/food bowl will be available to choose from). If, it turns out that the Makey kit works well with chains of food to conduct the signals, then I would like to incorporate that also, so players make their own connections. Imagine me, as the presenter, slicing an orange and overlapping the sections to allow a very tiny current that Makey requires, to be sent along the length. This particular overlapping sections idea is untested, but if it works, even for just a short length, it will be incorporated to add to the player’s involvement in creating the connections (itself artistic) in order to create the art.

No player made connections, no art is created or game like experience is enjoyed. So essentially, this is a very analog way of looking at DRM, as well as engaging the player. I have used “artist” and “player” to describe the same person interacting with my exhibit because both terms apply. Winning for the player will mean creating the connections to allow the “artist” side to help create the art. Until that artist decides they’ve done enough and leaves, and another artist can come along and generate even more art, evolving the images through their choices.

I am excited about this new direction, not just because I imagine it being visually engaging, both in a quick “come play with me” and a deeper “help me evolve this image”, but because of the practical side of this being very doable by the due date. Its simplicity will be both completable and engaging. After all this previous process with my earlier project idea, after all the research and testing, I agree with Prof. Galanter that my earlier idea presented very real issues with completion. This project can have an interesting design, as well as show attention to all three aspects: concept, aesthetics, and technology.

False game vs. True game (pragmatism)

I’ve found some examples of people who have gotten Arduino/Unity serial communication to work…

…on Windows.

On mac, which is what I’m using (I don’t own a Windows PC), this seems possible, but requires more programs to run in the background, more serial communication, and more potential bugs to work out. Some methods require custom plug-ins for Unity, which means a Unity Pro license (upwards of $1500, so no, not happening). Someone else got a good interface going with Max/MSP. I used this program last semester in my Electronic Composition class, so I do have some prior experience I could bring. But, all of this is putting more complexity into a relatively small aspect of my project. Links to two of the most promising looking examples with actual code are below. Consider these the swan song of the Arduino/Unity aspirations of this project.

Squeezy Cube

Arduino 2 Unity (Windows)

However, Arduino/Processing serial communication works fine on a mac, and is something that is already fully supported by both programs through already written libraries that simply have to be enabled at the start of the programs. My project, quite simply, is not a game design project and was never intended to be such. This is part technical demo, part art installation, but although serial communication between the controller and the “game” is required, that “game” being built in Unity is not. Processing can manipulate and display lit 3D objects in space. It’s not nearly as sophisticated as an actual game development IDE can accomplish, but can work just fine for my project. My game was never going to be complicated anyway. A circle/sphere moving over sections of the screen that light up in sequence would be fine for this. Because the real meat of my installation will be “player” interaction with the controller, not the game, this Arduino/Processing option is desirable.

Here is a link to my previous Physical Computing blog (first time through), when I completed an exercise in serial communication where sensor data was sent from Arduino to Processing. The code here will be very helpful in tweaking the handshake program to work with my project. It will be nice, when I’m designing the technical aspects of the controller, and the aesthetics of the controller, that I will have a handshake protocol to work from. It will be a helpful time saver.

I intend for the controller itself to be a game in a way. Winning will mean getting the controller to function in the game. The game will be the sequence of events the player (sometimes players) must accomplish to allow the controller to send input into the “game”. Wrong inputs or correct inputs not in the correct sequence could cause a loss of progress. For example, mess up too much in step 6, get pushed back to step 3 or 4, depending on the severity. This is the game, and the meat of the project; design the controller and the win condition of the controller as a game. A game that really makes the player think or act quickly, more akin to those schoolyard games like “Red Rover” or “Red Light, Green Light”. And I want to be able to put enough design time into the controller so it really looks inspired. So it will grab the eye and draw the player in, even before anyone plays it. So, what should it look like, where should the controls be placed in the design. These are the big artistic questions. Not what the visual monitor game will look like.

This is why I’ve put “game” (the false game) in quotes when referring to the graphical aspect on the monitor. That is not the game, the controller is the game (the true game).