CONCEPT

This midterm project explores the theme of illusion in Shakespeare’s “Macbeth,” focusing on the play’s intricate examination of hallucinations and the blurred line between reality and fiction. Inspired by a recent rereading of the tragedy, I was particularly drawn to Macbeth’s psychological descent and how it manifests through vivid hallucinations. The project aims to translate these literary elements into an interactive digital experience, allowing users to engage directly with Macbeth’s internal struggles.

Dagger Scene:

Central to the project is Macbeth’s first and perhaps most iconic hallucination: the floating dagger. This vision, occurring as Macbeth grapples with the moral implications of regicide, serves as a powerful metaphor for his ethical dilemma. The famous line, “I have thee not, and yet I see thee still,” encapsulates the frustration and confusion Macbeth experiences as he attempts to grasp the illusory weapon. This moment became the cornerstone of my project.

To recreate this sense of futility and frustration, I designed a scene where users must attempt to catch a floating, elusive dagger. Initially, I incorporated a probability variable to make the dagger challenging to catch, mirroring Macbeth’s inability to clutch the hallucination. However, after discussing with my professor, I realized this approach inadvertently removed an essential aspect of user agency and responsibility.

Therefore, instead of relying on probability, a ‘jittery’ random movement for the dagger seemed the best approach. This approach maintains the essence of Macbeth’s struggle while allowing users to feel fully responsible for their actions and failures. The erratic movement of the dagger not only represents the unstable nature of hallucinations but also challenges users to question their perceptions and reflexes, much like Macbeth questioning his sanity.

function moveDagger() {
  daggerX += speedX;
  daggerY += speedY;
  if (daggerX <= 0 || daggerX >= windowWidth - 200) {
    speedX *= -0.5;
    speedX += random(-2, 7);
  }
  
  if (daggerY <= 0 || daggerY >= windowHeight - 200) {
    speedY *= -0.5;
    speedY += random(-2, 7);
  }
  
    // jittery movement

  
  speedX += random(-0.5, 0.5);
  speedY += random(-0.5, 0.5);
  speedX = constrain(speedX, -5, 7);
  speedY = constrain(speedY, -5, 7);
}

 

BLOODY SPOT:

Once the user manages to catch the dagger, they have essentially helped Macbeth kill the king. Then we move onto the next scene, known as the ‘bloody spot scene’, which takes place in the context of after the murder, shifts focus to Lady Macbeth and her psychological unraveling due to guilt. This level/scene aims to immerse players in her descent into madness, mirroring her frantic attempts to cleanse herself of the metaphorical blood that stains her soul.

The gameplay mechanics are designed to reflect Lady Macbeth’s futile struggle against her guilt. Players will interact with various blood spots that appear on the screen, attempting to “wash” them away using a sponge cursor. However, just as Lady Macbeth’s efforts are in vain, more spots will appear even after being washed, illustrating the persistent nature of guilt and the psychological effects of their actions. I wanted to mirror her feelings into this, so I decided to create this cyclical gameplay.

To enhance this experience, the level also features a timer that counts down from 30 seconds. This time constraint adds urgency to the gameplay while emphasizing the fleeting nature of sanity as Lady Macbeth spirals deeper into madness. Unlike traditional games that have clear winning conditions, this level does not allow players to achieve a definitive victory; instead, it reflects Lady Macbeth’s tragic fate. When the timer reaches zero, players will be confronted with a poignant message about her inability to escape her guilt, culminating in a “Game Over” screen that reinforces the themes of ambition and remorse present in Shakespeare’s tragedy.

MENU

The menu design for this Macbeth-inspired game aims to create an immersive, gothic atmosphere that sets the tone for the entire experience. Drawing inspiration from the dark themes and supernatural elements of Shakespeare’s play, the design incorporates visual and auditory elements to engage the user from the moment they enter the game.

The background is set to black, immediately establishing a somber and mysterious mood. This dark canvas serves as the perfect backdrop for the text elements, allowing them to stand out and capture the user’s attention. 

The welcome message, “Welcome To Macbeth,” is displayed using a medieval font (UnifrakturMaguntia) in a blood-red color. This font choice evokes the historical setting of the play, while the red color symbolizes the bloodshed and violence central to the story. The welcome message appears word by word with a fade-in effect, creating a sense of anticipation and drawing the user into the world of the play.

Following the welcome message, a series of paragraphs introduce the story and set up the game’s premise. These paragraphs use a more readable serif font (DM Serif Display) in white, contrasting with the black background for clarity. The text appears gradually, line by line, allowing the user to absorb the information at a measured pace. This pacing mimics the gradual unfolding of the play’s plot and builds suspense. The final line, “If you are brave enough, click D,” serves as a call to action, challenging the user to engage with the game.

SOUND: 

Throughout all levels of my Macbeth-inspired game, sound plays a crucial role in enhancing the user’s interactive experience. I carefully selected and implemented audio elements to create an immersive atmosphere that aligns with the psychological journey of the characters.

Menu Level:

To set an eerie tone from the start, I incorporated audio from an actual performance of Macbeth’s first encounter with the prophecy that catalyzes his downfall. This choice immediately immerses players in the ominous atmosphere of Shakespeare’s tragedy.

Dagger Level:

In this pivotal scene, I layered the gameplay with a recorded performance of Macbeth’s famous dagger monologue. As players attempt to grasp the elusive dagger, they simultaneously hear Macbeth grappling with his moral dilemma. This audio-visual synergy deepens the player’s connection to Macbeth’s psychological state. Upon successfully catching the dagger, symbolizing Macbeth’s decision to commit murder, a sharp ‘slash’ sound effect punctuates the moment, aurally representing the finality and violence of his choice. In addition, I also added a fading effect – from white to black, to symbolize Macbeth’s descent.

Bloody Spot Level:

For Lady Macbeth’s scene, I opted for a more subtle approach with a general background soundscape. This audio backdrop sonically communicates Lady Macbeth’s internal turmoil and growing madness, enhancing the player’s understanding of her psychological plight without overpowering the gameplay.

Challenges:

I encountered a significant challenge with sound between scene transitions. Initially, audio from previous scenes would continue playing in subsequent levels, creating a chaotic and unintended soundscape. To resolve this, I implemented a sound management system where I call the .stop() method on all active audio elements at the beginning of each new scene. This ensures a clean audio slate for each level, maintaining the intended atmosphere and preventing audio overlap.

However, the most PROMINENT issue that I had (I spent two days trying to figure this out) was the sound — my sound in Menu (the prophecy audio) would play automatically when I run it in p5, like it should. However, when I go the full screen mode, the audio (the prophecy)  would not play, only when I would click ‘R’ to restart . I originally assumed that there was some conflict in my restartMenu() function. However, after tearing my code apart trying to figure out why the sound would not specifically play from full screen but would play in the preview/regular screen, I decided to turn to ChatGPT to see if it was able to recognise the problem. It immediately told me that it was due to my browser (I’m just happy there were no logical fallacies in my code) and how it handles audio autoplay. It told me that many browsers restrict automatic playback of sounds without user interaction, especially on initial load. Therefore, it just told me to use a built-in function from p5 called userStartAudio() — it explained to me that I should code a specific user interaction that can trigger the sound.

Thus this I coded:

function setupMenu() {

  background('black');

  medievalFont = 'UnifrakturMaguntia';

  paraFont = 'DM Serif Display';




  // to play audio

  userStartAudio();




  if (prophecy.onended ) {

      prophecyPlay = false;  

  }

}






function mousePressed() {

  if (!prophecy.isPlaying()) {

    prophecy.play();

    prophecyPlay = true;

  }




}

And my code now functions as expected when I go full screen!

This project has been the most insightful to teach me to be open to feedback, as well as really understanding the elements of  what it takes to make something interactive and functional.

This is the link:

WELCOME_TO_MACBETH

 

Project Concept:

I’ve always had a fear of snakes. Overcoming it seemed impossible until I started working on my game. Inspired by how snakes consume food whole, I had the idea of the game I am working on for my midterm called “Going Through It”. It is be an obstacle course game where the obstacle course is be designed in the shape of a snake. The player controls a small stick character trying to escape the snake as fast as possible. Adding my own unique twist to the game, the player cannot directly control the jumping ability of the stick figure, instead the stick is more akin to a ‘pogo stick’ where it bounces off with every obstacle it collides with and the player only controls the rotation of the stick figure using their keyboard.

User Interaction Design:

Player Input: The player uses the “A” and “D” keys to control the rotation of the stick figure. Player needs to angle the jump correctly to get through each part of the obstacle course.
Obstacles: The whole level design acts as the obstacle in this game, where the stick figure can bounce around by hitting walls or the insides of the ‘snake’ and can even get stuck in some traps laid out to make the game trickier to play.
Game Progression: As death is not an element of this game, the players race against themselves and other players to complete the level in the shortest possible time as they understand the mechanics of the game better.

Code Design: Functions, Classes, and Interactivity:

‘Going Through It’ is built using Object Oriented Programming (OOP) where every entity within the game belongs to a separate class that interact closely to make the game function.

The primary classes and their major functionalities are as follows:

Obstacle Class: The obstacle class defines the parameters for the rectangles make up the ‘snake’, it also contains functions such as display() which display the obstacles as one cohesive interactable object.

Stick Class: The Stick class defines the stick object itself and contains functions such as rotate() and update() which help establish rules for collision and input caused rotation. This serves as the biggest and most important class for the game code

Snake Level Class: The snake level class instantiates the obstacle class objects with coordinates to make one cohesive snake level and adds them to a list so collision checks can be performed.

Game Class: Game class deals with all functionality not handled by the other classes, this includes functions for pausing the game, showing the start screen, showing a lowest time, and starting the level itself. It also checks when a level has ended and displays a text with the time taken to clear the obstacle.

Identifying and Addressing Risks:
The most challenging aspect of the project is implementing accurate collision detection between the stick character and the obstacles. Since there are a multitude of angles the stick can collide with the obstacles with, figuring out accurate and responsive collision detection has involved a lot of trigonometry and I definitely believe there is more to come in order to account for all possible scenarios.

In order to mitigate the risk of the stick phasing through the level, or getting stuck at certain points I have tried to account for detection with each corner of the stick, each side vertical and horizontal and collision with vertical, horizontal and obstacle walls at diagonals. This is a tedious process and there is a lot of room for error which I am minimizing through meticulous play testing of the level.

Another risk I am trying to mitigate is the complexity of the level, as this is a single player game, a level that is too easy will make the game not enjoyable after a few playthroughs, on the contrary a level that is too complex and difficult to compete will cause players to quit and not wish to progress sooner. I hope to continue doing play testing, also involving friends who have never played the game before so that I can get input from them and adjust the level and individual paths within the level to make the game the perfect mix of complex but pushing people to beat the level in shorter and shorter times.

Snapshots from the game and further steps:

 

This is the design of the Snake Level, the time is shown in the top left corner and stops running once the level is completed

Next Steps:

Adding a Lowest Score: I want to keep a track of the lowest time achieved which is displayed on the game start screen and is meant to be an initial challenge for new players  to beat.

Start Screen: I want to add a start screen which shows, the level itself, the tutorial for the game and lowest time someone has taken to complete the level.

 

After watching Casey Reas’ talk, I’ve found my randomness and controlled chaos held within art. The way he intertwined randomness with controlled elements presented me with a unique perspective on creating art, showing how seemingly chaotic processes could yield meaningful and structured outcomes.

One of the standout examples from his talk was his work with cancer cell data, where he uses controlled randomness to produce distinctive visual patterns. This application of data not only served an artistic purpose but also pushed the boundaries of the interpretation of scientific information. It sparked a realization in me: the artistic process can be deeply intertwined with scientific exploration, leading to new interpretations and insights.

It was remarkable to see how even simple elements like dashes could serve as building blocks for more complex patterns. This idea compelled me to reconsider my creative practices. Instead of getting overwhelmed by the complexity of my projects, I now have the ability to start small and hopefully snowball into a project that I can be proud of.

Moreover, his talk provoked a deeper philosophical inquiry into the nature of creativity itself. If art can emerge from a system of randomness and algorithms, it challenges our conventional understanding of ownership and intentionality. In a time when machines contribute more and more to the artistic and creative process, is there a line we can draw regarding owning a piece of art or even whether something can be called art itself?

After Reas’ talk, I’m inspired to experiment more freely with randomness and tiptoe within the lines of control and chaos.

Golan Levin’s article on Computer Vision opened my eyes to the fascinating world of computer vision in art. As a computer science major also delving into the visual arts, I found this piece incredibly relevant to my studies and personal interests.
The historical overview of computer vision in interactive art was eye-opening. I was unaware of the fact that artists have been experimenting with this technology since Myron Kruger’s work in the 1970s. It’s amazing to see how far society has progressed in the past half a century and how artists continue to push the boundaries of what’s possible with these tools.
One thing that really stuck with me was the explanation of basic computer vision techniques. I’ve always been curious about how interactive installations work, and learning about motion detection and object tracking was akin to getting a peek behind the curtain. It was fascinating to think that these fundamental concepts are behind so many of the interactive artworks in galleries and online.
The article made me think a lot about the difference between human and machine vision. I never realized how much work goes into making a computer “see” things that we take for granted. The fact that algorithms have to assign meaning to visual data is mind-blowing. It makes me appreciate the complexity of human perception even more.
I was particularly intrigued by the ethical implications of using computer vision in art. The example of the Suicide Box by the Bureau of Inverse Technology made me think about the fine line between art and surveillance. As someone who wants to create interactive pieces, I’m now more aware of the responsibility that comes with using these technologies. How do we make sure we’re not invading people’s privacy while still creating engaging experiences? It’s definitely something I’ll be considering in my future projects.
I appreciated that Levin included code examples, so I could see firsthand the effort and technique that went into creating such pieces. In conclusion, this article has changed the way I think about interactive art. It’s not just about creating engaging and fun experiences anymore; it’s about understanding the technology behind it and using it responsibly. I’m looking forward to experimenting with computer vision in my own work, but I hope to be more mindful of the ethical considerations involved.