“The cleanliness of what can be seen only calls up the more clearly thoughts of what cannot be seen.”
Jun’ichiro Tanizaki – In Praise of Shadows
Our next project is a bath house. It leaves me to wonder what qualities of a bath house, besides a place of cleansing and rejuvenation, this kind of space could enclose. In thinking of a bath house, I begin to think about the process of bathing. There is a precedent, someone who has been in the fields tending to their crops all day, that they feel the need to relax. They approach the bath house, steam emanating from this singular structure situated in a serene setting, undress, and water molecules slowly fill their pores, the same pores desiccated by the searing sun earlier in the day. Steam continues to pour out, in gentle tufts carefully ventilated by slits on the roof. Twenty minutes, thirty minutes, almost an hour. The steam is no longer. The man emerges, still bare,
the fall semester is over and this blog was neglected for the better part of it. I thought I’d resolve this issue by using this as a collection of thoughts for the forthcoming semester, concrete. in this post is my work from the past semester, which I thought was deserving of an A based on effort, but I digress. here it is in summation:
these are just renderings, and the diagrams and programmatic models I left out intentionally, but know this is a firehouse based on experiential spaces. well, architecture is a process anyway.
Our final project is based upon the concept of creating a database of drawings. We wanted to use the framework of Draw Something! in order to create such a database, where players would draw a picture after being provided a word, and then guessing an existing picture. Since the complexity of the project was beyond the scope of the course material, we decided to remove some of the qualities of the game and brought it down to “Draw!”.
The process of designing a game as complex as draw something involves several classes. One of the key classes is the color swatch on the top of the screen. The start button would begin the database by calling upon a predetermined word and clearing the contents of the screen, which at the beginning of the game is simply the start button. The word is displayed on the top right corner, and the player uses the Kinect system (or a mouse) to draw the displayed word. Upon completion, the program should take a screen shot of the image drawn and save it into the database with the word pair, and display a drawn picture for the player to guess.
The second part of the project would have involved a guessing mechanism with 10 letters, x of which belong to the word itself and the rest filled with random letters. We created the class for this as a preliminary set up, but didn’t have the time or knowledge to complete this portion of the project.
At the end of the project, there would be a database with a series of words and a series of pictures paired to the word. It could be beneficial to observers to see how long it took a person to draw a particular picture, its complexity, and how long it takes for another player to decipher the drawing. I would be interested to see how players with certain handicaps, perhaps closing their eyes or drawing with their non-dominant hand would react to such changes.
A copy of the unfinished script can be found here.
For the final arch 430 project, Lauren and I decided to make something less complicated than the project outlined in a previous blog post. We decided that because of the complexity involved in writing code for four separate stations and having it sync to one source, we were going to follow the trends of handheld (mobile) gaming and make a kinect version of “Draw Something”.
Basically, we’ve dumbed down the game to make it easier to code since, to be frank, coding is a completely foreign language to the both of us. The player competes against the computer, and upon finishing a drawing, the player’s drawing is stored in the database to be accessed by another player. Through this process, we would have about 15 words with 100 different drawings for each word. We want to use this information later on to understand how people can interpret simple drawings at different speeds using different visual cues. Though the complexity of storing a drawing into the array is mind numbing, we’ve trudged through and hopefully will have a working prototype on Thursday.
The purpose of assignment 3 was to parse XML data into processing, using existing XML data of different x-positions, y-positions, widths, and heights. This data is turned into boxes and drawn using the draw() function. Using the Box class, we go through the data and pick out the information relevant to the boxes, and using getChildCount figure out how many boxes to make. The println() function prints to processing the information already provided in the XML data. The beauty of XML over traditional spreadsheet tables is that it is readable by computers and humans using code and pseudocode. For example, a box would be called as <box id=”1″ height=”40″ width=”50″></box> and through the script, draw a 40×50 size box. The script can be found here and screenshots below.
My idea of the final project is highly interactive. I was thinking of creating a new game that requires all four players, connected with a Kinect camera and a TV. The players become actors of a greater game, which is projected in the center of Crown Hall. The image above is a quick sketch of the set up. Each corner of the building will have a booth set up, designating their role in the game. In terms of programming and processing, the cameras will accept all visual input and the TV will output what the other players will see. However, none of the players will see what the audience sees.
The purpose of the game is to work together to overcome a certain challenge. Using no audio feedback, the players focus on miming their instructions, much like Charades, to the other players. The screen, I’d imagine, would be divided into four screens. The audience watches the four players in Center Core by the use of a projector on a screen, or maybe the projector would project onto the floor.
In terms of the game’s structure, I haven’t considered what types of challenges the players would endure together. I figure that it’d be some sort of sequence of puzzles, much like Myst. For example, player 1 may need to hold open a door while player 2 runs in to get a key from a cave, but since it’s so dimly lit inside, player 3 and player 4 hold mirrors to reflect the light. The challenges can be altered so the game doesn’t require four players at all times.
I imagine the most challenging aspect of this project, should we venture my way, is to coordinate the inputs between four different inputs into one “base”, and then programming a game so that each of the four inputs all control different variables in the game. In a dumbed down version of the game, I imagine a similar set up, but each of the players have a turn making their bodies into a certain shape–either their own creation or suggested by the game–and it is the other three players’ responsibility to match the pose or lose.