MIDTERM

CONCEPT:
For my midterm project, I decided to combine my two favorite things together, SpongeBob and my childhood game Geometry Dash (which was my first inspiration for the game).
I decided to be more creative and create my own version of geometry dash using Spongebob as my main theme. Furthermore, instead of jumping over obstacles, you have to jump over SpongeBob characters.
The main goal of the game is to score as many points as possible by avoiding colliding with an obstacle; it’s pretty simple. I also added a twist to it; there’s a feature where you can fuel up the power bar by gaining more points, which leads to a rocket mode effect where you can collect double points but instead of jumping, you’re flying. For the characters, I decided just to use png images online, which I will attach to the website at the bottom; however, to incorporate shapes and colour, I decided to use shapes and gradients to create the theme of the background, including the burgers and jellyfish. I also used a Spongebob font for the text to add more to the aesthetic. To organize my codes, because at some point it got messy, I decided to create multiple files, for functions and classes, which made it a lot easier as I knew where everything was and it was most helpful in debugging anything if there was an error.

HIGHLIGHT:
The code I’m most proud of is probably the jellyfish part of the game because it handles more than one thing like spawning, moving, and removing jellyfish, while also checking for player collisions. It also has conditional behavior since the jellyfish can only cause the game to end when the player is in rocket mode. I had to redo the code multiple times as there were a lot of errors in the beginning and I had to update multiple loops. Additionally, it depends on variables like `isRocketMode` and `gameOver` from other parts of the game, which makes it more complicated to manage since it must stay in sync with the overall game.
here is the code:

function updateJellyfishObstacles() {
  // Spawn new jellyfish obstacles at intervals
  if (frameCount % jellyfishInterval === 0 && jellyfishObstacles.length < maxJellyfish) {
    let jellyfishY = random(70, height - 80);
    let jellyfish = new Jellyfish();
    jellyfish.y = jellyfishY;
    jellyfishObstacles.push(jellyfish);
  }
   // Update jellyfish obstacles and handle rocket mode collisions
  for (let i = jellyfishObstacles.length - 1; i >= 0; i--) {
    jellyfishObstacles[i].move();
    jellyfishObstacles[i].show();
    
    // Remove off-screen jellyfish
    if (jellyfishObstacles[i].offScreen()) {
      jellyfishObstacles.splice(i, 1);
      continue; // Move to the next jellyfish
    }
    
    // Only trigger game over if the player hits a jellyfish while in rocket mode
    if (jellyfishObstacles[i].hits(player)) {
      if (isRocketMode) {
        deathSound.play();
        gameOver = true;
      }
      
    }
  }
}

 

IMPROVEMENTS:
In the future, I would probably like to add more elements to the game as it gets repetitive. Also, if I had more time I would fix this upside-down section of the game, as I feel like it looks odd in some sort of way, since the obstacles are upside down but not the player. Moreover, I would also improve the way the obstacles are shown in the game, as I fear they aren’t visually clear or hurt the eyes when you look at it too long, and it is because its moving fast, however, if its too slow, the game would be easier.

Here is the game:

 

REFRENCES:
https://www.jsdelivr.com/package/gh/bmoren/p5.collide2D. (my collide reaction HTML)
https://www.fontspace.com/category/spongebob (font)
https://www.pngegg.com/en/search?q=spongebob (all my images)

MIDTERM

CONCEPT:

The idea for my project initially came from my nostalgia for Fruit Ninja.

Fruit Ninja Classic - Halfbrick

This was a game I enjoyed during my childhood, and I wanted to capture that excitement in my own way. I began by recreating the core mechanics: objects falling from above, mimicking the action of fruits being thrown up in Fruit Ninja. The player interacts by catching these items, with some scoring points and others, like the scorpions, leading to an instant loss. It took me a while to fine-tune these functions and get the timing, speed, and interactions to feel as responsive and engaging as the original game. At first, I struggled with the mechanics, as I wanted the motion and flow to feel natural and intuitive, just like in Fruit Ninja.

After a lot of trial and error, I was able to get the objects falling at varying speeds and from random positions, which gave the game a sense of unpredictability and challenge. I also added a cutting effect, just like in the game. This process helped me understand the importance of small details in game development, such as timing and object positioning. I also experimented with different speeds and sizes to make the game challenging yet enjoyable. The initial version was simple, but it felt exciting to see it come to life and mirror the familiar feeling of Fruit Ninja while incorporating my own twist. Here’s how it came out:

However, as I progressed, I realized that directly copying Fruit Ninja wouldn’t fully reflect my own creativity or bring anything new to the experience. This led me to reflect on my childhood memories. I recalled family trips to the desert in the UAE, where we would snack on dates and sweets under the open sky. I remembered the joy and the relaxed environment, but also my fear of scorpions, which were common in the desert. It struck me that this blend of joy and tension could provide a compelling twist to the game. I decided to adapt Fruit Ninja’s concept to incorporate elements of these desert trips. Instead of slicing fruits, the player would catch falling dates and sweets in a basket to score points, which was the cultural twist I wanted to add. Dates and traditional sweets, which are common in Emirati gatherings, served as the main items to catch, reflecting my childhood memories of trips to the desert with family. However, there was also a twist that added suspense to the game: scorpions. Just as scorpions are a real concern in the desert, they posed a threat in the game. If the player accidentally catches a scorpion, the game instantly ends, mirroring the risk and danger associated with encountering one in real life. To add more depth, I included power-ups like coins for extra points and clocks to extend the timer. These power-ups fall less frequently, requiring the player to remain alert and responsive. This combination of culturally inspired items, the risk of game-ending threats, and occasional rewards created a gameplay experience that balances fun and challenge. The game’s aesthetic, from the falling items to the traditional Arabic music, all contribute to the cultural theme. Overall, the game became not just a nostalgic tribute to Fruit Ninja but also a playful representation of a personal childhood experience infused with elements of Emirati culture.

HERES MY GAME:
LINK TO FULL SCREEN: https://editor.p5js.org/aaa10159/full/rZVaP6MKc

HIGHLIGHT OF MY CODE:

The gameplay mechanics involve the basket interacting dynamically with various falling items, including sweets, dates, scorpions, and power-ups. Each of these elements serves a unique purpose in the game. For example, catching sweets and dates earns points, catching a scorpion ends the game, and catching power-ups like coins or a clock offers bonuses that enhance the gameplay experience. Integrating these interactions smoothly required attention to detail and precision in coding, as I needed to ensure that each item type was recognized and handled correctly by the basket.

To handle collisions between the basket and the falling items, I implemented a collision detection method within the basket class. This method calculates the distance between the basket and each item, determining if they are close enough to be considered “caught.” If they are, the game then applies the appropriate action based on the type of item. This collision detection is crucial for the game’s functionality, as it allows the basket to interact with different items dynamically.

// Define the Basket class, which represents the player's basket in the game.
class Basket {
  // Constructor initializes the basket with an image and sets its position, size, and speed.
  constructor(img) {
    this.img = img;           // The image used to represent the basket.
    this.x = width / 2;       // Horizontal position, initially centered on the screen.
    this.y = height - 50;     // Vertical position, near the bottom of the screen.
    this.size = 150;          // Size of the basket, controls the width and height of the image.
    this.speed = 15;          // Movement speed of the basket, determining how fast it can move left or right.
  }

  // Method to control the movement of the basket using the left and right arrow keys.
  move() {
    // Move left if the left arrow;is pressed and the basket is within screen bounds.
    if (keyIsDown(LEFT_ARROW) && this.x > this.size / 2) {
      this.x -= this.speed;   // Update the x position by subtracting the speed.
    }
    // Move right if the right arrow is pressed and the basket is within screen bounds.
    if (keyIsDown(RIGHT_ARROW) && this.x < width - this.size / 2) {
      this.x += this.speed;   // Update the x position by adding the speed.
    }
  }

  // Method to display the basket on the screen.
  display() {
    // Draw the basket image at its current position with the specified size.
    image(this.img, this.x, this.y, this.size, this.size);
  }

  // Method to check if the basket catches an item (e.g., a date or power-up).
  catches(item) {
    // Calculate the distance between the basket's center and the item's center.
    let distance = dist(this.x, this.y, item.x, item.y);

    // Check if the distance is less than the sum of their radii.
    // If true, this means the basket has caught the item.
    return distance < this.size / 2 + item.size / 2;
  }
}

In this code, the ‘catches()’ function plays a central role. It calculates the distance between the basket and the center of each item. If this distance is smaller than the sum of their radii (half their sizes), it means the item is “caught” by the basket. This collision detection method is efficient and works well for circular objects, which is perfect for the various falling items in the game.

By using this approach, I was able to ensure that the basket can accurately catch power-ups, dates, and sweets, and also end the game when a scorpion is caught. It’s a simple yet effective way to handle interactions between the player and game objects, which is essential for my game. This method also ensures that players can control the basket smoothly, making it feel natural as they try to avoid scorpions and collect items to score points.

FUTURE IMPROVMENT:

One of the specific challenges I encountered was perfecting the basket’s interaction with falling items, particularly when it came to maintaining accuracy in collision detection. Initially, I found that the items would sometimes pass through the basket without registering a catch, which was frustrating. To resolve this, I adjusted the bounding boxes for each object and tuned the distance calculations in the ‘catches’ function. However, this process revealed another area for improvement: the scorpion’s animation. Currently, the scorpion is static, but animating it would add a dynamic and slightly intimidating effect, enhancing the player’s experience.

Another improvement I’d like to make involves expanding the game by introducing different game modes. Currently, the game focuses on catching dates and sweets while avoiding scorpions, but I envision adding modes with unique objectives and challenges. For instance, one mode could intensify the difficulty by increasing the speed of falling items, while another could introduce new types of falling objects that require different strategies to catch or avoid.

Additionally, I would like to explore a survival mode where players have to last as long as possible, with gradually increasing difficulty as more scorpions and fewer power ups appear over time. By adding these game modes, It would offer players more choices and variety, encouraging them to keep playing and exploring new strategies within the game. This would not only add depth to the gameplay but also align with my goal of making the game more engaging and enjoyable for a broader audience.

 

 

Midterm Project: Labyrinth Race

Concept:

Sketch Link: p5.js Web Editor | Labyrinth Final (p5js.org)

Inspired by the Greek myth of Theseus, who navigated the labyrinth to defeat the Minotaur, I envisioned a game that captures the thrill of navigating a maze to reach a goal. In this two-player game, only one can survive the labyrinth. Players must race to the safe zone at the center of the maze while avoiding touching the walls of the maze. The first player to reach the center wins, while the other faces death. Alternatively, if a player touches the walls at any point, they are immediately eliminated, granting victory to their opponent by default. This intense competition fosters a sense of urgency and strategy as players navigate the ever-changing labyrinth.

Design features:

  • Dynamic Maze Generation: Each time a new game begins, the maze layout changes, ensuring that no two playthroughs are the same. This feature keeps the gameplay fresh, challenging players to adapt to new environments every time they enter the labyrinth.
  • Boundary Enforcement: Players are confined to the game canvas, ensuring they stay within the limits of the maze. Exiting the bounds is not an option.
  • Customizable Player Names: Players can personalize their experience by entering their own names before starting a match. For those who prefer to jump right into the action, the game also offers default character names, maintaining a smooth and accessible start.
  • Animated Player Sprites and Movement Freedom: Each player is represented by a sprite that shows movement animations. The game allows Movement in 8 directions.
    EightDirMovement21
  • Fullscreen Mode: For a more immersive experience, players can opt to play the game in Fullscreen mode.
  • Collision Detection: The game includes collision detection, where touching the maze walls results in instant disqualification. Players must carefully navigate the labyrinth, avoiding any contact with the walls or face elimination.

Process:

The most challenging and time-consuming aspect of this game was designing the maze. The logic used to ensure that a new maze is generated with every iteration involves several key steps:

Maze Initialization: The process begins by drawing six concentric white circles at the center of a black canvas, with each subsequent circle having a radius that decreases by 60pt. This creates the foundational layout of the maze.

let numCircles = 6; // Number of white circles in the maze
let spacing = 50; // Spacing between circles

// Loop to draw white circles
for (let i = 0; i < numCircles; i++) {
    let radius = (i + 1) * spacing; // Calculate radius for each circle
    noFill(); 
    stroke(255); 
    strokeWeight(2); 
    ellipse(width / 2, height / 2, radius * 2, radius * 2); // Draw each circle
}

Black Circle Placement: Black circles are then placed randomly on top of the white circles. The innermost black circle is erased to create a clear entrance. The number of black circles on each white circle increases as we move outward, adding complexity to the maze design.

// Function to generate positions for the black circles
function generateBlackCircles() {
    // Loop through each circle in the maze
    for (let i = 0; i < numCircles; i++) {
        let radius = (numCircles - i) * spacing; // Start with the outermost circle first
        let maxBlackCircles = numCircles - i; // Outermost gets 6 circles, innermost gets 1
        
        // Generate random positions for the black circles
        for (let j = 0; j < maxBlackCircles; j++) {
            let validPosition = false;
            let angle;

            // Keep generating a random angle until it is far enough from other circles
            while (!validPosition) {
                angle = random(TWO_PI); // Generate a random angle
                validPosition = true; // Assume it's valid

                // Check if the angle is far enough from previously placed angles
                for (let k = 0; k < placedAngles.length; k++) {
                    let angleDifference = abs(angle - placedAngles[k]);
                    angleDifference = min(angleDifference, TWO_PI - angleDifference);
                    if (angleDifference < minAngleDifference) {
                        validPosition = false; // Too close, generate again
                        break;
                    }
                }
            }
            // Calculate the coordinates and store them
            let x = width / 2 + radius * cos(angle); 
            let y = height / 2 + radius * sin(angle);
            blackCircles.push({ x: x, y: y, angle: angle, radius: radius });
            placedAngles.push(angle); // Save the angle for future spacing
        }
    }
}

Collision Detection for Black Circles: An overlap function checks to ensure that no two black circles spawn on top of one another. This is crucial for maintaining the integrity of the maze entrances.

// Function to check if the midpoint of a line is overlapping with a black circle
function isOverlapping(circle, x1, y1, x2, y2) {
    let { midX, midY } = calculateMidpoint(x1, y1, x2, y2);
    let distance = dist(midX, midY, circle.x, circle.y);
    return distance < circleRadius; // Return true if overlapping
}

Maze Line Generation: For each black circle, a white maze line is generated that is perpendicular to the white circles. Another overlap function checks whether the maze lines overlap with the black circles, adjusting their positions as necessary.

// Function to draw the lines from the edge of the black circle
function drawMazeLines() {
    stroke(255); // Set the stroke color to white
    for (let i = 1; i < blackCircles.length - 2; i++) {
        let circle = blackCircles[i];
        // Calculate starting and ending points for the line
        let startX = circle.x - (50 * cos(circle.angle)); 
        let startY = circle.y - (50 * sin(circle.angle));
        let endX = startX + (50 * cos(circle.angle));
        let endY = startY + (50 * sin(circle.angle));
        // Check for overlap and adjust rotation if necessary
        while (isAnyCircleOverlapping(startX, startY, endX, endY)) {
            // Rotate the line around the origin
            let startVector = createVector(startX - width / 2, startY - height / 2);
            let endVector = createVector(endX - width / 2, endY - height / 2);
            startVector.rotate(rotationStep);
            endVector.rotate(rotationStep);
            // Update the coordinates
            startX = startVector.x + width / 2;
            startY = startVector.y + height / 2;
            endX = endVector.x + width / 2;
            endY = endVector.y + height / 2;
        }
        line(startX, startY, endX, endY); // Draw the line
    }
}

Test Sketch:

 Final Additions:

  • Player Integration: I introduced two player characters to the canvas. Each player was assigned different movement keys and given 8 degrees of movement as players needed to utilize their movement skills effectively while avoiding collisions with the maze walls.
  • Collision Detection: With the players in place, I implemented collision detection between the players and the maze structure.
  • Game States: I established various game states to manage different phases of the gameplay, such as the start screen, gameplay, and game over conditions. This structure allowed for a more organized flow and made it easier to implement additional features like restarting the game.
  • Player Name Input: To personalize the gaming experience further, I incorporated a mechanism for players to input their names before starting the game. Additionally, I created default names for the characters, ensuring that players could quickly jump into the action without needing to set their names.
  • Sprite Movement: I dedicated time to separately test the sprite sheet movement in a different sketch to ensure smooth animations. Once the movement was working perfectly, I replaced the placeholder player shapes with the finalized sprites, enhancing the visual appeal and immersion of the game.
  • Audio and Visual Enhancements: Finally, I added background music to create an engaging atmosphere, along with a game-ending video to show player death. Additionally, I included background image to the game screen.

Final Sketch:

Future Improvements:

One significant challenge I encountered with the game was implementing the fullscreen option. Initially, the maze generation logic relied on the canvas being a perfect square, which restricted its adaptability. To address this, I had to modify the maze generation logic to allow for resizing the canvas.

However, this issue remains partially unresolved. While the canvas no longer needs to be a perfect square, it still cannot be dynamically adjusted for a truly responsive fullscreen mode. To accommodate this limitation, I hardcoded a larger overall canvas size of 1500 by 800 pixels. As a result, the game can only be played in fullscreen, which may detract from the user experience on smaller screens or varying aspect ratios.

Moving forward, I aim to refine the canvas resizing capabilities to enable a fully responsive fullscreen mode.

 

Midterm Project – Moves

Game Design

After receiving feedback and asking my friends to play through the game draft, I made some changes to the original game design:

  • Player control: Instead of mouse movement  + keyboard movement, I decided to use full keyboard movement.
  • Implementing two different obstacles instead of one: rock and destroyable dancing keys.
  • I initially plan to make the game full screen, however, the player movement will then be too wide and decrease the difficulty of the game when the character moves around to avoid asteroids.

End game and winning mechanism: a progress bar to track how many obstacles the player has destroyed. If player manages to stay alive and fill the whole progress bar, they win. Else if player used of all of their lives, they lose. I also give the player 9 lives as a reference to the saying “cats have 9 lives”.

The player lose lives when: got hit by asteroids, miss a key or press the wrong key.

Story

I am particularly proud of the story and implementation of arts in this game. I have experience with coding before, so I decided that for this project in IM I want to make the game more conceptual and tell a comprehensive story.

I draw a few scenes at the start of the game to create a storyline for the cat hero. The story is about a normal cat who enjoys music but one day a extraterrestrial comet hit the Earth and gave him superpower that can be unlocked with his dance moves. With great power came great responsibility, he has to use his power to protect the Earth from alien invasion.

All of the arts in this game or created by me except for the background photo, the asteroid and the heart in the winning screen.

Main character – cat hero drawn by me with background photo generated by AI

Final game (size 400×400)

Struggles

The main struggle I have was with the game design. I was basing my game on normal dancing game, for example, Just Dance now. However, there are some factors I want to change, mainly the movement left and right of the character, hence, the same game mechanism does not work very well for my game. After the first game demo, I realized what was missing from my game was response to the player interaction. For example, key disappearing or asteroid disappearing when interacting with users. In the final, I make the asteroid disappear after hitting the cat and implement a progress track bar for the scores. However, if I have more time to work on this project in the future, I would implement sound response or visual cue like displaying the key user just pressed or signs when user loses live.

Reflection

Making game has always interested me before and I really enjoyed making this midterm project, especially the story telling part. Some particular part I identified to improve in the future are sound design and visual design. Some feedback I received from my friend also help me think about the game design. For example, a feedback I received was how the asteroids were coming towards the Earth and the cat was avoiding it instead of destroying it, which clash with the storyline. I think it’s a good observation that I did not realize when creating the game.

WEEK 5: review

I found the reading, which breaks down computer vision and its applications in art, to be interesting; however, I have some opinions. I totally agree that computer vision has expanded from military and law enforcement applications to more creative fields like art and gaming. This shift is really exciting as it creates numerous opportunities for artists and programmers to explore and innovate. Also, I found it interesting in the reading when it shows how beginners can make computers “see” by using basic methods like frame differencing or background subtraction, which increases accessibility to the technology.

However, I feel the reading is somewhat overly positive regarding the capabilities of computer vision in “seeing” things. It’s known that computers can track objects and people, but the reading doesn’t highlight enough how much more challenging it is for computers to grasp what they’re observing compared to humans. Humans, for instance, may easily understand a chaotic scene, whereas computers frequently require specific conditions, such as bright light and different objects and background contrast.

The reading reminded me of the game Just Dance. The game tracks your movements while you dance using computer vision technology. It’s enjoyable, but it doesn’t always hit the mark. If your room lacks sufficient light or the camera isn’t positioned just right, the game may struggle to accurately track your movements, which can be quite frustrating. I think the reading should focus more on how computer vision struggles in imperfect situations, even though technology has the potential to produce amazing interactive experiences.

Finally, the reading points out worries regarding the potential use of computer vision for tracking and surveillance purposes. This is something to keep an eye on. It’s enjoyable and imaginative in gaming and artistic pursuits, but it has the potential to invade personal privacy. In general, the reading could have presented a more balanced view by discussing the downsides more and not just highlighting the positives; however, I found it to be interesting when it was breaking down the computer’s vision in a way I hadn’t thought about before.

Midterm Progress: Defeat the Minotaur

Concept:

I’ve been reading books on Greek mythology lately, and I’ve noticed how certain tropes keep resurfacing in these tales. Anyone familiar with Greek myths knows that labyrinths are a huge aspect of these stories. Like, take Orpheus, who went into the underworld to bring back his dead wife. His story brought people to tears, and it really showed how much of a maze the underworld was and how insane it was for him to brave that journey.

Since I’m a literature major too, I thought I had the thought of working on a project that would be a fusion of both of my majors for once. That’s how I got the idea to create my own labyrinth game, which if the name of the project does not already give away— is an adaptation of the Greek myth of Theseus, who went into the Minotaur’s labyrinth to defeat him.

Knossos Palace in Assassin's Creed Odyssey: A Historian-Scientist ...

 

But, honestly, if I were in Theseus’s shoes, my strategy wouldn’t be to kill the Minotaur. With my very human physique, I’m not cut out for that. I’d be focused on getting to safety instead. So, the idea for this game is simple: you start with a circular maze that has multiple entrances around the edge. There are two players — one using the arrow keys to move and the other using WASD. At the start of the game, each player must choose a separate entrance to the maze, and the goal is to find their way to the safe zone in the center before the Minotaur catches them. Once a player reaches the safe zone, both players can’t move anymore, and the one who didn’t make it gets eaten by the Minotaur.

MYTHS OF THE LABYRINTH | Ashmolean Museum

Players can choose to play as Theseus or Orpheus, and the game also ends if anyone touches the boundary walls of the maze.

Design:

The maze itself will be created using vectors. Each segment of the labyrinth will be drawn programmatically, ensuring that the structure remains consistent while allowing for flexibility in the maze’s layout. For the characters, I’ll use a sprite sheet to handle movement animations, enabling smooth transitions between different frames as the characters navigate through the maze.

In terms of the pseudo-algorithm for the game:

1. Maze Construction: The maze will be created using vector functions. I’ll define an array of vectors to represent the maze walls and entrances. This will allow for flexible maze design. The setup() function will initialize the canvas and call a function to draw the maze based on pre-defined parameters.

2. Player Movement: Two player objects will be created, each with properties for position and speed. The players will respond to keyboard inputs, with Player 1 controlled by the arrow keys and Player 2 using WASD. The draw() function will include a movement handler that updates each player’s position based on key presses.

3. Safe Zone Mechanism: A function will check if one of the players reaches the safe zone. When this occurs, the game will stop updating the players’ positions. This can be handled with a simple boolean flag that controls movement.

function checkSafeZone() {
    if (dist(player1.x, player1.y, safeZone.x, safeZone.y) < safeZone.radius) {
        gameActive = false; // Stops player movement
    }
}

4. Minotaur Appearance: The Minotaur will be an object with properties for position and movement speed. When the safe zone is reached, a function will activate the Minotaur, setting its initial position off-screen. The Minotaur will then move towards the player outside the safe zone using a straightforward pathfinding algorithm or direct movement logic.

5. Game Over Condition: A function will determine if the Minotaur reaches the player outside the safe zone. If they collide, the game will trigger a game over state, displaying who won and include restart button.

The Challange:

 

Making the Minotaur move toward the player outside the safe zone feels like a challenging task for a few reasons. First, I need to allow the Minotaur to override the boundary wall constraints, which means it would glide over any obstacles on the screen to reach the player. Since the Minotaur won’t be restricted by the usual collision detection that applies to the maze walls, it should make it a little simpler to implement the tracking mechanism.

To implement this, I envision starting with a function that checks which player is outside the safe zone. From there, I’ll need to determine how to return the coordinates of that player so the Minotaur can track them effectively. The tricky part is figuring out how to make the Minotaur move towards those coordinates. I’ll need to increment or decrement its x and y positions based on the player’s location.

The real challenge lies in determining when to increment or decrement. I need to devise a way for the program to recognize the Minotaur’s position relative to the player’s coordinates. This means creating conditions that account for whether the Minotaur is to the left, right, above, or below the player. Getting that logic right will be crucial for smooth movement, and I can already tell it’s going to take some trial and error to nail down the precise mechanics.

Risk Management:

To reduce the risk of encountering major issues while programming the Minotaur’s movement, I’ve taken several proactive measures. First, I’ve broken down the implementation into manageable tasks, focusing on one aspect at a time, such as determining the player’s position outside the safe zone before programming the Minotaur’s movement. This incremental approach allows me to test each function independently and ensure that everything works as expected before integrating it into the game.

Additionally, I’ve researched pathfinding algorithms and movement logic used in similar games, which has given me insights into best practices for implementing smooth character movement. I’m also making use of clear comments in my code to keep track of my thought process and logic, which should help me debug any issues that arise more easily.

Finally, I’ve set up a simple testing framework where I can run the game at various stages of development. This way, I can identify potential problems early on and address them before they become larger obstacles.

 

 

MIDTERM PROGRESS

MY CONCEPT:

I made the decision to design a game for my midterm project in the style of the vintage game Fruit Ninja, which was hugely popular a few years ago. I chose Fruit Ninja because it was known for its simple yet addictive gameplay. In the original game, fruits are thrown into the air, and the player must slice them by swiping across the screen. The goal is to slice as many fruits as possible while avoiding bombs. If a player slices a bomb or misses multiple fruits, the game ends. The game progressively increases in difficulty as more fruits and bombs appear on the screen while the timer is running out.

In my version, the game remains similar to the original concept, but instead of swiping, the player uses the mouse to slice fruits as they are thrown into the air. However, I’ll be adding a ninja using a splice sheet, which will make it more fun for the user to interact with. As the game progresses, more fruits and bombs are thrown to increase the challenge. Each sliced fruit increases the score, but if the player slices a bomb, the game ends instantly. My version also gradually increases the difficulty over time by speeding up the fruit and bomb spawn rate, which is a similar addictive experience to the original Fruit Ninja. Also, I’ll be adding music in the background and sound effects for the fruits being sliced and the bomb being triggered. Overall, the goal of the game would be for the user to earn points and beat there high score. It sounds boring, but the interactions within the game are what will make it fun.

In terms of design, I aimed to keep the visuals simple yet engaging, with vibrant fruit images, smooth animations, and a clean background. I wanted to add fruit-slicing effects, which include splatters, to make the game feel dynamic and immersive, similar to the original Fruit Ninja experience. Also, I want to create explosives when the bomb gets triggered. For the background, I will keep it similar to the original game by adding wooden planks. As for the texts, I want to make them bold red or colorful like the fruits (still deciding) and also have them in Japanese text style. Also, as I said, I will incorporate music to make the game lively and as fun as the real game.

USER INTERACTION:

User interaction is central to the experience of my game. Players will use the mouse to slice fruits by hovering and clicking across the screen. The simplicity of using just one hand to interact makes it easy to pick up, while the increasing challenge keeps it engaging. The addition of the ninja character and slicing animations adds a layer of fun to the interaction. As players progress, they’ll need to be more precise and quick as the number of fruits and bombs on the screen increases. Also, I wanted to add something like a bonus fruit, where it would have more value than the other fruits and power-ups to keep it fun. The mouse-based game offers a fluid way to engage with the game, making the experience more immersive. Sound effects will provide immediate feedback for actions, which will make the user’s interaction satisfying while slicing or the warning of an approaching bomb/exploring.

MY MOST COMPLEX PART:

My game’s most challenging component is making sure the game ends smoothly and without needing a page refresh while managing the sound effects. That’s why I’m going to add a gameEnd flag that stops all in-game events, like fruit and bomb spawns, and shows a game-over screen when a bomb is cut or the timer runs out. Background music and sound effects will stop when the game is over, giving the player a clear break. Im also going to add a way to start the game over again from the screen that says “Game Over.” This way,  the user won’t have to refresh the page. Another challenge is ensuring that multiple sound effects, such as slicing fruits and triggering bombs, don’t overlap or cause audio clutter. In order to avoid this, I will manage sound channels and test various scenarios to make sure the sound effects are smooth and don’t collide, enhancing the overall user experience. In the end, I’m still looking for ways where this can successfully go smoothly, and this is what I’ve come up with so far regarding this issue.

MY PROGRESS:

This is just the base of my game. As you can see, the game is still not smooth, and the fruit is getting thrown everywhere; however, I’m still adjusting to it to make it work better. I just incorporated the fruits, the bomb, half of the test, and the background. I still need work on it by adding sounds and the ninjas to finalise this code, as well as fixing on the smoothness issue. Also, I’m still working on the instruction page and how the user can go on from that.

 

Reading Reflection 4

Computer Vision for Artists and Designers:

In reflecting on this paper on computer vision, I find its potential utility for artists and designers both compelling and distinct from human vision. The difference between computer vision and human vision mostly comes down to senses—humans use their five senses to process information, while computers need fixed algorithms to handle physical or visual data. But once that data is processed, we can program the computer to trigger a specific action based on what it sees.

A lot of the techniques in the paper revolved around pixel tracking, which is basically comparing one pixel to a predefined one until a match is found. This could be useful in something like a salad-sifting machine, where I could train the model to recognize red pixels as tomatoes and have it remove all the red objects, essentially removing all the tomatoes from my salad.

As for how computer vision’s ability to track and surveil affects its use in interactive art, I think it’s a double-edged sword. On one hand, it’s amazing for creating immersive, responsive art that can change depending on how people interact with it—like tracking movement or emotions to alter the artwork in real-time. But at the same time, the idea of constant surveillance can be slightly problematic, especially in art spaces where people want to feel free and unobserved. So, there’s this tension between using computer vision to enhance interactive experiences and making sure it doesn’t cross any lines when it comes to privacy.

Reading Reflection – Week 5: Computer Vision for Artists and Designers

One way computer vision differs from human vision is in which computer vision uses sensors, which is almost similar to the human eyes, except their ‘vision’ is not an image but more like bits of information. Though both ‘visions’ need to be understood, the process for a computer would be longer and more complicated in which information has to be internalized and run through a series of program.

To help the computer see we must make the object of attention to be easily visible by either having it be a very bright light, so the computer can track the brightest pixel, or have it in an environment that contrasts the desired object to be tracked/seen (like against a green screen)

As much as it is interesting and cool, the idea of computer vision in relation to surveillance will always come with privacy concerns, especially as seen with the Suicide Box project by the Bureau of Inverse Technology. I think there should be some type of consent from both the artist and those that interact with the art. However with art like the Suicide Box, there is no consent and it all just seems like an invasion of privacy.

Reading Response 5:

Computer vision and human vision differ in interesting ways. While human vision is natural and intuitive, allowing us to recognize patterns and emotions effortlessly, computers need specific algorithms to make sense of images. For instance, what we instantly understand as motion or objects, computers detect through methods like frame differencing or background subtraction. I honestly find it intresting how rigid and task-specific computer vision is compared to our flexibility. Furthermore, to help computers “see” what we want, it uses techniques like brightness thresholding or background subtraction, and sometimes adjusts the physical environment by using better lighting or reflective markers.
Moreover, in interactive art, computer vision creates exciting new opportunities but also brings up ethical questions. For instance, Videoplace used computer vision to create playful, full-body interactions, while Standards and Double Standards used it to explore themes of authority and surveillance. However, a question that popped into my mind is that, when you consider the ability of these systems to track movements and gestures, do you feel like the line between creative interaction and surveillance can sometimes blur? This reminded me of the movie M3GAN, where AI uses computer vision to care for a child, but the surveillance becomes invasive. What if we might see something similar with interactive art or technology, where the systems that are meant to engage us could start to feel more like surveillance. Hence, it’s an interesting balance between enhancing the experience but also respecting privacy.