Author: Jennifer Cheung

Project Title: Labyrinth

Partner: Jonathan Lin

Project Statement of Purpose

Our project aims to create an engaging and nostalgic game inspired by Greek mythology’s telling of an intricate maze, where hero Theseus battled a beast called the Minotaur. The game involves two players, who will control either the Minotaur or Theseus within the labyrinth, each with different goal. The Minotaur aims to catch Theseus, while Theseus aims to find his way out of the maze. This game intends to create a fun method of engaging fans of obstacle games with Greek mythology, making its stories more accessible outside of academics. 

Project Plan

The game will be displayed in Processing and controlled in Arduino. At the start of the game, players will be prompted to play a minigame in order to determine their character’s speed within the maze. Each will wear a heart rate sensor and to raise their heartbeat within a short period of time by doing any kind of physical exertion. The heart rates will determine their character’s speed within the maze, with higher rate translating into faster speed. After the minigame ends, a birds eye view of the labyrinth will appear on Processing, with both the Minotaur and Theseus within it. Players will use a joystick to control their characters’ movements, with the Minotaur trying to catch Theseus and Theseus trying to escape the maze. The game ends when either player meets their goal. The game will challenge its players to move quickly, but also assess the maze for the most efficient navigation.

I will focus on Processing visuals, such as creating the maze, characters, layouts, and other graphics, while Jonathan will focus on Arduino code. We will also construct a laser cut box to create a joystick console for easier usage. Visuals should be done by the start of the week of May 6, and have Arduino combined with Processing a couple days before the week of May 13 to leave room for user testing. Through testing, we will be able to see how people interact with the game and make the necessary improvements for easiest playability. 

Context and Significance 

I define interaction as a breakable cycle in which two or more actors’ outputs build off of and enact direct causation onto each other. One actor’s output is directly a unique result of other’s output. Our project aligns with this definition because the users enact change in the game, which influences their future actions. First, players physically engage in the game by increasing their heart rate, which determines a change in how fast their characters will go. Players then move the joystick to control their players in the maze, causing prompt response on Processing, indicated through changing character positions. This cycle of players’ actions and the game’s responding indicators allow for mutual engagement that is reliant on each other.

Our project involves physical activity and mental strategy, engaging more of the player than most video games do. With the thematic allusion to Greek mythology, our project has the capacity to not only be an entertaining game, but also an educational introduction into Greek myths. In recreating the labyrinth into a game, players are able to involve themselves in the classic story under a new context of technology. The labyrinth goes from a story read in literature to a game that they can experience themselves. 

Our game is intended for fans of obstacle games, who enjoy being physically and mentally challenged. Hopefully, the game can inspire players to dig deeper into the story of the labyrinth and other Greek myths. After successful completion, the project can be expanded to include other obstacles within the maze and more mythical characters, which would make the game more close to mythology and challenging to play. This would heighten the experience of playing the game.

For this recitation, I used serial communications to utilize both Arduino and Processing to use hardware and software interactions together.

In the first project, I made a Processing Etch-A-Sketch with Arduino potentiometers. I used the sample code for Arduino to Processing communications as a starting point, modifying the Processing code to map the posX and posY as width and height. On the breadboard, two potentiometers controlled the x axis and y axis movement. I then drew an ellipse moving across the screen, but the ellipses drawn were not continuous enough to come across as a line. So, I changed it to a line function, using prevPosX and prevPosY to remember the previous position of the line in order to make the line draw. Arduino code stayed the same. 

Next, I used the Arduino to Processing sample code to make a music player with a buzzer on the breadboard. I used the mouse position of an ellipse to translate into sound frequency in Processing and linked it into the Arduino code. So, the tone would change based on where my mouse was on the canvas. Using an if/else statement in Processing, I was able to get the tone to play only when a key was pressed. 

My initial definition of interaction from the group project was defined as the engagement between at least two actors who produce variable outputs that are interdependent on each other’s inputs. I feel that my current understanding of interaction falls along the same lines, but it can be reworded to be more inclusive of more projects. My midterm project was a game that involved competitively shaking acceleration sensors in order to put all the LED lights out the fastest. This represents interaction to me because users had an effect on the game’s LED indicators, which in turn had an effect on how users continued to shake the sensors. However, the use of the word “interdependent” in my definition may be too strict to encompass projects like these. While the game depended on the user to change the state of the LEDs, the user didn’t depend on the game to create shaking movements. They each had an effect on the other, but it wasn’t truly interdependency. 

Soonho Kwon, Harsh Kedia and Akshat Prakash’s Anti Drawing Machine is a perfect example of interaction. The machine disrupts or acts as a collaborator as is made on a normal piece of paper based on how the user draws. It utilizes Arduino and A4988 stepper motor drivers to change the rotation and position of the paper serendipitously to create whimsical and imperfect drawings. Inconspicuous sensors detect where the drawer is drawing, and moves the paper accordingly in unpredictable ways. This falls under interaction because the machine depends on the user to make movements, while the user must change the way they draw in order to accomodate for how the machine moves the paper. They are engaging each other to make different movements.

Skin Drag is a project that does not align with my definition of interaction. SkinDrag is a watch that drags a physical tactor across the skin beneath the watch in order to communicate notifications physically. This was made to create a stronger stimulus than normal phone vibrations, since the tactor movements vary depending on the type of notification received. I don’t see this as interaction because the watch and the wearer do not each have an effect on each other. The watch affects the wearer by creating a physical stimulus, but the wearer has no effect on the watch. Instead, the watch gathers data from an external source to create its movements. Therefore, there is no direct mutual interaction between the wearer and the watch. 

I now define interaction as a breakable cycle in which two or more actors’ outputs building off of and enacting direct causation onto each other. One actor’s output is directly a unique result of other’s output. I include “unique” to describe these outputs in reference to Chris Crawford’s description of the refrigerator door opening and closing to turn on the light inside. I do not see this as interaction, because the light turns on regardless of how the door is opened. Regardless of speed or force, the light will turn on if the door is opened. For this to count as interaction, the light would have to turn on in varied ways, for example, turning different colors or exerting different brightnesses depending on how someone opens the door, since these are unique responses to the action that vary each time. I also describe it as a breakable cycle because these outputs are continually mutually changing in response to each other until one actor does not produce an output anymore. With one output stopped, the other output will also stop in response to this deficit of input until the cycle is begun again. 

Works Cited:

Crawford, Chris. The Art of Interactive Design: a Euphonious and Illuminating Guide to Building Successful Software. No Starch Press, 2003, pp. 3-6.