As I have mentioned in my Midterm Progress Report, my goal was to create not just a game, but rather an interactive environment for which I took inspiration from the game I played a long time ago with my friends.

It was a long journey from the beginning to the end of my work that included not much but, still, some challenging parts that I will describe later in this blogpost.

Concept

Initially, I wanted to create an interactive game related to Christmas Eve, and simply work on good-quality visuals and add certain interactions, e.g. opening the gifts. However, after getting feedback from the professor and thinking about other potential ideas, I realized that it would not be enough for me to be fully satisfied with the results. That is why I decided to add the game that would also include good-quality animations and sprites, and would incorporate the collision detection and OOP principles.

As it needed to also be related to Christmas, I decided to make the Santa the main character of the game. Initially, I wanted to do something with the landscape orientation as my game is pretty wide. However, I decided to reject that idea because of the potential problems with the screen movement control. (For my laptop, for example, as it has a small screen, the game exceeds the boundaries of the monitor, so I need to scroll through the screen).

I decided to implement the game with the basic concept of ‘something falling from the sky, and you either need to dodge it or catch it’. Nothing special, but I strived to make it as fun as possible. In my game, the background poster inside the house tells that there is a shortage of gifts. The goal of the user is to help Santa to catch the gifts while dodging the icicles falling from the sky. The user can control the character by using the arrow keys.

Talking about the broader picture outside of the mini-game that I just described, my game consists of two main stages, outside the house (serves mainly aesthetic purposes with very nice background music that I received multiple compliments about haha), and inside the house (platform for interactions and ‘entrance’ to the mini-game).

PLAY THE GAME IN THE FULLSCREEN (PRESS ‘F’ FOR THE FULL FULLSCREEN)

Problems and Solutions

Although there were not too many problems, there were enough difficulties and struggles that it will not be possible to fit here, so I will focus mainly on those that I’m actually proud of resolving.

1) By my mistake, the biggest struggle was to connect the games together. Yes, you read it right. Connect the games.

For some reason, I was naive enough to think that p5.js has a function that can magically embed one sketch into another. Don’t get me wrong, p5.js is an amazing platform with many functionality and features to offer, but I expected such a concept of unification to exist. Exactly why, I decided, to make things easier and write the code for my mini-game in the separate file. It was to my big surprise to realize, after an hour of trying, that it is impossible to just straight up integrate the mini-game into my main file. So I needed to put a lot of work and precision into the transfer of the code, and, at some points, to hardcode, to plug the mini-game into the screen of the main game as you can see playing it now.

} else if (currentScene === 4) {
  // Game scene
  playGameSceneMusic();
  image(blurred_house_interior, 0, 0, 1800, 900);
  fill(0, 147, 255);
  rect((width - sceneGameWidth) / 2, (height - sceneGameHeight) / 2, sceneGameWidth, sceneGameHeight); 
  
  isMouseOnArrow = checkIfMouseOnArrow();
  drawArrow(); // to be able to exit back to scene 2
  
  if (!gameStarted) {
    displayRulesScreen();  // rules
  } else if (gameOver) {
    displayGameOverScreen(); //game over
  } else if (gameWon) {
    displayWinScreen(); // win
  } else {
    playGame(); // game state

2) Music and Sound effects were not behaving as intended. The main problem was the repetitiveness and infinite looping of the sounds during the interactions with the object. For example, a knock on the door would repeat itself from the start to the finish all the time while the mouse is pointing at it. I needed to fix it using the limiting boolean conditions (true/false). I hope you get what I mean by this. If you don’t, perhaps it will be easier when you’ll look into the code.

if (mouseX > doorX && mouseX < doorX + doorWidth && mouseY > doorY && mouseY < doorY + doorHeight) {
  doorTrigger = true;
  
  if (doorKnockCharged === true) { // to play sound once per mouse pointing 
    doorKnock.play(); 
    doorKnockCharged = false;
  }
} else {
  doorTrigger = false; 
  doorKnockCharged = true; 
}

3) Screen scrolling with the arrow keys did not allow to make the experience of playing the mini-game enjoyable. The Santa movements are bonded to the Left Arrow and Right Arrow. At the same time, as I have mentioned above, my screen, as I expect to be for most users as well, was too short, so the picture of the game is scrollable in the fullscreen mode. In p5.js, arrow keys trigger the screen scrolling, which interrupted the mini-game flow as the screen waas constantly moving left and right with the key clicks. I even posted the question in the discord channel, but after the internet research I found the solution.

// blocking arrow key default behavior using window event listener
window.addEventListener("keydown", function(event) {
  if (event.key === "ArrowUp" || event.key === "ArrowDown" || event.key === "ArrowLeft" || event.key === "ArrowRight") {
    event.preventDefault();  // Prevent default scrolling behavior
  }
});

 

4) When opening the gifts and the mini-game, I needed to come up with the background to be used. As looking for new backgrounds would take too much time, I decided to make it in a similar way many games do – blur the background to make the effect of focus on the chosen item. Initially, I tried to implement it using the filter(BLUR, ...) function in p5.js. Although the effect looked nice, for some reason, my game started lagging and freezing during the scenes with using the blur (probably has something to do with the constant update of pixels on the screen). So I decided to make a little smart move – instead of blurring the picture inside the game, I blurred the picture using the blurring tool on the internet and simply plugged it into my sketch.

PLAY THE GAME IN THE FULLSCREEN (PRESS ‘F’ FOR THE FULL FULLSCREEN)

Conclusion

I am very proud of my work on this midterm project. I accomplished more than I initially planned to, and I managed to maintain a more or less high standard of gaming. I found good quality images, sounds, and sprites, I successfully handled the unexpected difficulties, and managed to build the game without significant bugs (hopefully there are no bugs at all haha). Most importantly, I achieved my initial goal of creating an art piece of nostalgia for myself, and I did it by putting in a lot of hard work and thinking processes. Of course, there are a lot of things that I could add to the game or implement in a better way, for example using less hardcoding and following a more logical and organized approach. I could make more high-level effects or create better-quality textures, etc.. Unfortunately, it was not enough time to accomplish all that I could.

Nevertheless, I am happy with how the course is going so far. I have a lot to learn and grasp, and it keeps me excited and motivated for the second half of the course. Looking forward to working with Arduino!

Concept:

The game is an arena-style, two-player game where each player controls a snowball. The goal is to either knock the opponent’s snowball (represented by an emoji image) out of the arena or collect three coins. Which ever player gets to three points first wins. A scoreboard is displayed on screen to show each player’s current score and coin count.

Sketch:

User Interaction: 

• The game begins with an instruction screen, requiring user input to proceed.
• Player 1 controls their snowball using the WASD keys, while Player 2 uses the arrow keys.
• Players navigate the arena, collecting coins or attempting to knock their opponent out of bounds.
• The first player to collect three coins or knock their opponent out three times wins.
• Players can choose to start a new session after completing the game.
  

  Implementation: 

• The game has several classes, each of which contributes to different aspects of the experience:

  • Game: This class manages the overall state of the game, including showing screens, handling instructions, tracking game progress, and determining when a round or the game ends.
  • Player: The Player class handles all of the attributes and behavior of each player. This includes movement (based on keyboard input), collision detection, score tracking, and boundary constraints.
  • Arena: The Arena class defines the boundary within which players compete. It is used to detect if a player has fallen out of bounds.
  • Item: The Item class is used to create collectible items (coins). When a player collects an item, it increases their coin count.

  Key features incorporated into the game:

  • Object-Oriented Programming: The game is structured using classes such as Game, Player, Arena, and Item to ensure modular and reusable code.
  • Visuals: The game uses images for players, the background, and items (coins).
  • Sound: Sounds are used for collecting coins and when the game ends.
  • User Input: Player controls are managed using keyboard inputs (WASD and arrow keys).
  • Collision and Boundary Detection: Players can collide with each other, and boundary detection is used to check if players fall out of the arena.
    

    Key Challenges Faced: 

    One of the primary challenges faced during development was handling the collision physics between the players. The snowball collisions had to feel dynamic, but it was difficult to achieve perfect elasticity. The physics calculations were complex, especially considering that each player’s position and velocity had to be updated to reflect an elastic collision.

    Another challenge was optimizing the game so that it could run smoothly in p5.js. Initially, I wanted to incorporate more images and sounds, but p5.js struggled to handle all of the resources, leading to long loading times. Ultimately, I had to simplify the assets to ensure smooth gameplay.

Code That I Am Proud Of: 

I am particularly proud of the resolveCollision() function in the Player class, which handles the collision between players. The function calculates the angle and then applies new velocities to the players to simulate the effect of a collision. This code makes the game feel more dynamic and fun, as players can push each other around the arena.

resolveCollision(other) {
  let dx = other.x - this.x;
  let dy = other.y - this.y;
  let distance = Math.sqrt(dx * dx + dy * dy);

  if (distance < this.radius + other.radius) {
    let angle = Math.atan2(dy, dx);
    let v1 = Math.sqrt(this.vx * this.vx + this.vy * this.vy);
    let v2 = Math.sqrt(other.vx * other.vx + other.vy * other.vy);

    let newVx1 = v2 * Math.cos(angle);
    let newVy1 = v2 * Math.sin(angle);
    let newVx2 = v1 * Math.cos(angle);
    let newVy2 = v1 * Math.sin(angle);

    this.vx = newVx1;
    this.vy = newVy1;
    other.vx = newVx2;
    other.vy = newVy2;

    let overlap = (this.radius + other.radius) - distance;
    let moveX = overlap * Math.cos(angle) / 2;
    let moveY = overlap * Math.sin(angle) / 2;
    this.x = this.x - moveX;
    this.y = this.y -moveY;
    other.x = other.x + moveX;
    other.y = other.y + moveY;
  }
}

This function might not achieve perfect elasticity, but it gives a satisfying collision effect, enhancing the overall player experience.

Reflection: 

Looking back, I am mostly satisfied with how the project turned out, especially given the challenges with collision detection and resource optimization. One thing I wish I could improve is the collision physics—ideally, the collisions would be perfectly elastic, allowing for even more realistic interactions between the players. However, achieving this in a way that felt right with p5.js was more challenging than expected. Despite these challenges, the game is enjoyable and provides a satisfying experience for both players.

Concept

I created an interactive zoo-themed game where players get to dive into the fun of feeding different animals. The game features a variety of enclosures, each housing unique animals like a Lion, Elephant, Giraffe, and Bear, along with their distinctive images and sounds. The main goal is to correctly feed each animal their preferred food while managing a limited number of attempts. It’s all about exploring the zoo, having fun, and seeing how well you can feed the animals! The gameplay is designed to be engaging and straightforward. Players drag and drop food items into the enclosures, trying to match the right food with the right animal. It’s a lively experience that captures the excitement of a day at the zoo while keeping players entertained and challenged.

What I’m proud of the most is how the zoo home looks like:

Code Snippets

I’m proud of the code for the feedback system; it plays distinct sounds for correct and incorrect food choices, while also displaying visual messages. This helps the player learn from their mistakes in real time.

checkFood(chosenFood) {
  if (chosenFood.name === this.correctFood) {
    correctSound.play(); // Play the correct sound if food is right
    correctFeeds++; // Increment correct feeds count
    gameWon = (correctFeeds === zoo.length); // Check if all animals have been fed correctly
    showCorrectMessage = true; // Show correct message

    // Stop the sound for the current enclosure
    for (let enclosure of zoo) {
      if (enclosure.name === currentEnclosure) {
        enclosure.stopSound();
      }
    }
  } 
    else {
    wrongSound.play(); // Play the wrong sound if food is wrong
    lives--; // Decrement lives
    
    // Check for loss condition
    if (lives <= 0) {
      gameOver = true; // Set gameOver to true if lives reach zero
    }
  }
 }

Another code snippet I’m proud of is the mousePressed function because it lets the player easily move from the instruction screen to exploring the zoo, and if they win or lose, it resets everything for a fresh start. The way it checks if an enclosure was clicked and responds to player actions keeps the gameplay fluid and intuitive, making it simple for anyone to jump in and play without getting stuck.

function mousePressed() {
  if (instructionScreen) {
    instructionScreen = false; // Exit instruction screen when clicked
  } else if (gameOver || gameWon) {
    // Reset game state and go to instruction screen
    lives = 3;
    correctFeeds = 0; // Reset correct feeds count
    gameOver = false;
    gameWon = false;
    instructionScreen = true; // Reset to instruction screen
    currentEnclosure = null;
    for (let enclosure of zoo) {
      enclosure.stopSound();
    }
  } else if (currentEnclosure === null) {
    // Check if an enclosure is clicked
    for (let enclosure of zoo) {
      enclosure.checkClick();
    }
  } else {
    // Reset showCorrectMessage for the next animal
    showCorrectMessage = false;
  }

The Good Parts

The game runs on a combination of object-oriented programming and easy-to-understand mechanics. Each animal enclosure is an instance of the Enclosure class, complete with its own attributes like size, name, images, sounds, and the specific food it needs. Players simply drag and drop food items into the right enclosures, and the game gives instant feedback on whether they made the correct choice or not.

I’m really proud of how I integrated audio into the game. Each time players make a correct or incorrect choice, they hear distinct sound effects that add a fun layer to the experience. Plus, I included on-screen messages that help players understand what they did right or wrong, making it easy to learn and improve. I also love how the design encourages players to explore different enclosures and challenges, creating a loop of fun that keeps them engaged. The restart feature is a nice touch too, allowing players to jump right back in if they want to try again after finishing a round.

The Not So Good Parts

Even though I’m happy with how the project turned out, there are definitely areas where I could improve. For instance, the user interface could use a bit more flair to make it visually appealing. Sprucing up the background and button designs would enhance the overall experience. I also want to fine-tune the drag-and-drop mechanics to make them even smoother, as some players might find it tricky to place the food just right.

During the development process, I faced a few challenges along the way. One significant issue is that there are still some bugs that I didn’t have time to fix. For example, players can exploit a loophole where feeding the same animal the correct food four times counts as a win, which isn’t the intended gameplay experience. Additionally, if players don’t drag the incorrect food item away before placing the correct one, both the correct and wrong sounds will play simultaneously, which can be confusing. I also noticed that the food items tend to stick together when they touch, almost like magnets, which adds an unintended dynamic to the dragging mechanic. However, when players switch to another enclosure, the food items reset as intended, which is a positive aspect. These challenges highlighted the importance of thorough testing and debugging, and I plan to address them in future iterations of the game.

Groovy Derby: Link To Fullscreen

Groovy Derby: Link To P5

Concept:

The concept for my project was inspired by the co-op game It Takes Two, where two game characters set out on a journey that is filled with cooperative minigames and obstacles which they have to overcome. As such, I wanted to create a minigame where the game is only “playable” if two people are communicating and working together. Combining with themes from arcade games such as a limited number of lives and endless generative spites, I created Groovy Derby where two players have to input the correct order of key combinations in order to score points in the game.

Project Workings:

For my project, I am extremely happy with the character design and the way that they move and interact with each other. Although they don’t move from their position, the way the characters match each other movements in almost an animated way had relived me of a lot of stress. Particularly because I was really worried, I wouldn’t be able to have the characters move in a certain way and the game would look super chunky/ blocky. I think looking at animations and working frame-by-frame really helped my character movements, and in the end I had 5 frames/ designs for the characters to move. If there is anyone looking for “animated” characters, I recommend breaking down the movement into pieces and seeing how they would look on screen.

On the technical end, I am happy with the game mechanics and interactions between the user input with the creatures. I also really worried on how to connect the key pressed and possible decrement of the combination from the creature encroaching onto the characters. For that, I created player and creature class methods that checked the first combination with the input of the user, and if it matched, then the first combination would be removed. If it was the wrong input, the creature would keep moving towards the center, and if it reached a certain range within the players, a life would be lost.

As for improvement on the code, I believe the code can be more optimized as some parts were copied pasted, then the variable was changed to match what I was trying to do. I wish there were more randomization in the code because after round 6, there is a 1/3 chance for any of the creatures to be loaded in. On the game design part, I wish there were more user feedback such as when a life is lost, when a button is pressed, when the game is starting, additional sound effects, etc,. However, given we had ~1.5 to 2 weeks to complete this project, I am happy with the end result and progress that I was able to implement into my project.

Player Class

let playerHead = width / 33; // ~50 pixels
let distanceApart = width/ 26 // ~65 pixels
let player1 = new playerCharacters(player1Color, distanceApart, 0, playerHead);
let player2 = new playerCharacters(player2Color, -distanceApart, 0, playerHead);

player1.player1Moves();
player2.player2Moves();
player1.playerHitBox(player2);

Final recommendations for people on a time crunch, but want their design to look nice, I had used Canva to design a lot of my background and additional image/text that didn’t need to move. For the game sounds, I went to a free sound effect website and download clips, then looped it in p5. For custom fonts, I went to a free custom fonts website and make sure to have a .ttf file or it might not work as intended. Last, I want to mention that the heart design was generated was AI generated because I couldn’t determine the vectors/ shapes needed for my design.

 

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.

Inspiration:

In this project, I aimed to create a dynamic visualization of baby names by ethnicity, year, and gender using data from a CSV file. The inspiration for this project came from the realization that names are not just identifiers; they often carry cultural significance and reflect societal trends. By exploring how different ethnicities and genders influence naming patterns over time, I wanted to highlight the diversity and richness of society. This interactive visualization allows users to engage with the data, making it easier to understand how names evolve and resonate within various communities within the US. The data for the USA was readily available and organized, and thus I decided to pick that as my dataset.

Code that I am particularly proud of:

One of the sections of my code that I am particularly proud of is the get_top_names function. This function processes the CSV data to extract the top ten baby names based on user selected criteria including ethnicity, year, and gender. This code tallies the occurrences of each name and sorts them to ensure that the most popular names are displayed in the visualization.

// This function processes the provided data to get the top 10 names
function get_top_names(ethnicity, year, gender) {
  let names = {};
  for (let row of table.rows) {
    // filters the data based on our current selection
    if (row.get('Year of Birth') === year && row.get('Ethnicity') === ethnicity && row.get('Gender') === gender) {
      let name = row.get("Child's First Name");
      let count = parseInt(row.get('Count'));
      // sums up counts for each name to account for duplicates
      if (name in names) {
        names[name] += count;
      } else {
        names[name] = count;
      }
    }
  }

Final Product:

Conclusions and Reflections:

Reflecting on this project, I recognize the power data visualization holds in uncovering trends and fostering human understanding and comprehension. I learned how to manipulate data and create interactive elements that allow users to explore and compare information. However, there are several areas for improvement. For instance I hope to incorporate additional features such as user-input filters or a broader range of years. I hope to also include an overlay feature where two separate bar charts can be compared on the same canvas, this could be useful for example if someone wants to more clearly see the trend of a certain name through time. Additionally, I plan to improve the aesthetics of the visualization by experimenting with different color palettes and designs to make it more appealing. Overall, this project has been a valuable learning experience, and I look forward to applying these insights in later projects.