Category: F2025 – Aya

Concept:

For my midterm project, I decided to create a football obstacle game where the player dribbles through moving defenders to score against a moving goalkeeper. The game gets progressively harder after each goal: defenders increase in number and speed, and the goalkeeper moves faster. The player clicks to shoot when near the goal.

The aim is to design a game that is fun and interactive, combining timing, precision, and quick thinking. I will also include engaging visuals and sounds to give feedback for player actions, like kicking the ball, scoring, or colliding with defenders. This makes the game feel immersive and responsive.

Design:

The game starts with an on-screen instruction explaining the controls: the arrow keys to move, and the mouse click to shoot. Only when the player presses a key or clicks the button does the game begin. The player, defenders, goalkeeper, and the ball in the game will be represented using circles for simplicity and visual consistency. The player will be a larger colored circle that moves freely across the field in response to user input, with the ball represented as a smaller circle attached to the player while dribbling. Defenders will be smaller circles in distinct colors, moving along random paths to create challenges, while the goalkeeper will be a medium-sized circle that moves horizontally along the goal line to block shots. When the player shoots, the ball will separate from the player and travel independently toward the goal.

Classes to be used:

• Player Class: Controls movement and shooting. Properties include position, size, and speed. Methods: Methods or functions include display(), move(), and shoot()

• Defender Class: Moves across the field, increasing in number and speed as the game progresses. Properties include position, size, speed, and direction. Methods or functions include display() and move()

• Goalkeeper Class: Moves left and right along the goal line. Properties include position, width, height, and speed. Methods or functions include display() and move()

• Ball Class: Moves toward the goal when shot. Properties include position, size, speed, and moving. Methods or functions include display(), move()

Gameplay Flow:

1. Start Screen: Displays instructions like “Use arrow keys to dribble, click to shoot, avoid defenders.”

2. Gameplay:

   • Player moves freely around the field with the ball

   • Defenders move continuously in patterns.

   • Player avoids collisions with defenders.

   • When near the goal, clicking the mouse shoots the ball.

3. Scoring & Difficulty:

   • Passing the goalkeeper scores +1.

   • After each goal, more defenders appear, defender speed increases, and goalkeeper speed increases slightly.

   • Player position resets for the next attempt.

4. Restart / New Session:

   • Players can restart without refreshing the page.

   • Score and high score are displayed.

Frightening/Challenging Aspect:

The most challenging aspect of this project will likely be keeping the ball consistently attached to the player while allowing free movement around the field. Although the player and ball are conceptually separate objects, the ball must move in perfect sync with the player in all directions – up, down, left, right, and diagonally, which can be difficult to achieve smoothly. This challenge becomes even greater when combining it with collision detection against multiple defenders and a moving goalkeeper. The ball must remain attached until the player decides to shoot, at which point it detaches and moves independently toward the goal.

But this is also the most important part of the project, and implementing it correctly will help create an engaging and fun experience.

Risk Reduction:

To reduce the risk of issues with keeping the ball attached to the player, I plan to implement a step-by-step testing approach. First, I will start by coding the player and ball as separate objects and linking the ball’s position directly to the player’s coordinates with an offset, ensuring that it moves smoothly in all directions. I will test this initially without any defenders or a goalkeeper to confirm that the ball follows perfectly. Next, I will gradually add collision detection with a single defender, then multiple defenders, and finally the goalkeeper, checking at each stage that the ball remains properly aligned. Additionally, I will use simple shapes, such as circles, for all objects to simplify calculations.

I’ve always thought of digital art and computer vision as really complex concepts, almost intimidating, because they felt so tied to technical expertise. What I appreciated about Levin’s article is how he breaks it down so it feels a little less intimidating. Reading it, I realized that these tools don’t always need to be heavy or advanced to be meaningful; even simple algorithms can create powerful, interactive experiences. 

That point resonated with me because I’ve actually worked on a VR project before for a class final. It was a “build your own concert” type of game, and looking back, I can see how much it connected to the kind of work Levin describes. We weren’t doing anything revolutionary with the code, but the way people could move and interact with the environment really made the experience. Especially since our target audience was those who can’t attend concerts due to health concerns. His emphasis on preparing the environment as much as the software clicked with me here. 

One of the main ways human and computer vision are different is through interpretation. While we humans can think outside the box, make different connections, see things from various angles, and recognize their different forms. Computers see things as a set of pixels and only ‘think’ in terms of structured algorithms. It’s very literal. What happens when we combine both?

This is why I was especially drawn to Krueger’s Videoplace. I’d read about him in Understanding IM before, and I’ve always liked his idea of using the human body itself as the interface. It made me think about how Steve Jobs framed the first iPhone: our fingers are the “best pointers out there,” which is why touchscreens felt so natural. It’s a reminder that sometimes the most effective tech feels the least like “technology” and the most like an extension of ourselves.

At the same time, I couldn’t help but think about the ethical side. While Levin highlights the playfulness and creative potential of computer vision, I also worry about issues like privacy and misuse. As an artist or designer, you can try to account for these risks, but sometimes it’s beyond your control once the technology is out in the world. For me, that overlap between limitless creativity and real-world responsibility is something I want to keep in mind as I continue building my portfolio in IM.

Overall, this reading made computer vision feel less like an intimidating black box and more like a tool I could actually experiment with. It left me curious not just about what I can create, but about how to do it thoughtfully.

Concept

Well, for my project, I have always been really inspired by the Japanese art of Kintsugi (金継ぎ). What I love about it is the philosophy of it that, instead of hiding the cracks in broken pottery, it highlights them with gold. It treats the breakage and repair as a beautiful part of the object’s history, and I find that to be incredibility interesting. This is why I want to bring that idea into a digital space.

For now, I think I’ll call my project the “Kintsugi Canvas.” I don’t intend it to be a typical drawing tool; I want to build an interactive artwork where your first action is to break something. You simply shatter a digital canvas with a click, and then watch as the program algorithmically mends the damage with simulated gold, creating a unique piece of art from the flaw you introduced. Of course, this is the base idea for now, but I’ve been thinking about the kind of object that I want to be fixed; is it a bowl that the user breaks and then repairs again? (as seen in the photo below). Well, I’m not decided yet, but pretty sure it’ll be among those lines. Of course, my goal is to make it like a game, so I want to fit all these elements together.

Gameplay Loop

The core gameplay loop is a simple, two-step journey that puts the player in the role of both destroyer and observer.

*** Shatter: The player’s primary action. A single click on the blank canvas triggers a fracturing process. Cracks spread dynamically from the point of impact, breaking the canvas into unique polygonal shards.

*** Mend: The game’s generative response. Once shattered, the system automatically traces the new cracks with an animated golden seam, “healing” the canvas. The player watches as a beautiful, final artwork emerges from the damage they initiated.

For now, till I decide on the actual technicalities of the game, I’ve decided to keep controls are minimal and intuitive: click to start a new round, press ‘S‘ to save your creation, and ‘R‘ to reset the canvas. These, of course, will increase once I have decided on the idea completely.

So, to state it simply, the game will give the users places to go to and from there they can shatter or mend. For now, I’m planning on a museum, bedrooms, personal times, etc. Some examples I’m planning to incorporate as the base are:

You simply choose an object, and you can shatter it, mend it, etc!

The Core Design Challenge

For the game to be compelling, the act of breaking the canvas has to feel satisfying and organic. The biggest technical and design challenge is probably generating crack patterns that look natural. A static or predictable pattern would make the core mechanic feel repetitive and robotic, ruining the player’s experience. The entire project hinged on making this moment of destruction feel alive.

The Solution

To brainstorm, I’m planning a concept focusing entirely on this procedural generation, a system of agents I call “growers.” Each grower is a point with a position and direction that carves a path. By giving these agents a simple set of rules—move, wander slightly, branch occasionally, and die on collision—complex, organic patterns emerge, which is totally needed for the project.

Concept

For my midterm project I have decided to create an adventure mystery game where the user is taken through an interactive journey where they make decisions based on clues provided to them. The game has different paths with different possible endings, giving the user control over the narrative of the story. With the starting point being in a long hallway where they will receive their first clue before entering the room, with the use of signifiers and feedback to lead the user where they need to be. Once the door is opened they are in the first room where they are supposed to make the first choice that decides which path they will be taking. Through this project I hope to bring together everything we’ve learnt so far technically and conceptually to bring the project to life and make it as engaging and interesting as possible.

Code Design

Character.js:
Represents a simple character with a body and head that can be drawn anywhere.

Hallway.js:
Draws the hallway, handles wall scaling, door animation, and hallway character.

Room.js:
Draws the rooms (intro, basement, office) and manages buttons and room characters.

Sketch.js:
Main controller that sets up p5.js, loads assets, switches between hallway and rooms, and handles input.

Current Progress

I have created an outline of the starting path of the game, particular the hallway and introductory room where the user makes their first choice. As well as a rough outline of what the first two rooms will be like. For the hallway I have integrated sound effects and a little walking and door opening animation to create an environment that draws the user in as soon as they start the game.

Challenges

Reflections

Working on the rough outline of what I want my project to look like and creating a skeleton for my code was very beneficial in learning what is the right way to approach this project. I now have a cleared idea of the path I’d like to take with this work and what I want to focus on. My first next step would be focusing on the narrative and the different storytelling elements that I will be integrating to guide the user. I feel like I need to focus on creating a path that is easy to follow and come up with reasonable signifiers.

For my midterm project, I’m making a driving game where the player controls a car and navigates through traffic. The car stays in place on the screen, and the world around it moves to create the illusion of motion. Players can control their car’s lane position and adjust their speed with the arrow keys.

The design centers on creating a believable driving experience in which the player is encouraged to drive recklessly. The player manages their speed while avoiding collisions with NPC cars, which follow traffic-like behavior with different speeds depending on their lanes. Headlights add an element of strategy, as flashing them can occasionally cause a slower car in front to switch lanes. Speed cameras introduce a sense of tension by encouraging players to manage speed carefully.

The code is organized with:

• • A Player class for position, speed, and headlights.

• • An EnemyCar class for NPC vehicles with varying lane speeds.

  • A Road and Environment system that handles moving lane markings, roadside trees, and cameras to simulate forward motion.

  • A main game loop that updates movement, detects collisions, and handles interactions between different classes. (e.g. Radar object detecting the Player object, Player object tailgating the EnemyCar object).

The most complex part so far has been creating the illusion of motion. Since the player’s car stays in one place, I needed to make the road, lane markings, trees, and other cars move dynamically to trick the eye into feeling like the player is driving forward. To minimize this risk, I prototyped moving background elements and tested different speeds for roadside objects versus lane lines. These tests helped me establish a convincing sense of motion, which makes the game feel much more immersive.

Sketch so far

Vision for humans can vary. Some might not be able to distinguish colors properly. Others may need glasses to focus on little details, or see what is slightly farther away from them. However, one thing remains consistent, what humans see is not what they choose to see, but what is in front of them. They can’t see a pool if there is not a pool in front of them. If there is a house, they will see a house. However, a human’s vision will also vary on different factors: the brightness, the colors arounds them, the state of an individual’s eyes, and more. On the other hand, computer vision relies mostly on algorithms, pattern and feature recognition, etc. However, all of these are process, that, as described in the text, if they are low-level computer vision, they won’t even be able to resister a person or object in a video, making it flawed and susceptible to making crucial mistakes if not programmed properly. Nonetheless, this arguably shares a similar trait with humans when their vision is not 20/20, hinting that computer and human vision are both prone to having flaws.

One useful technique, aside from the others mentioned in the reading, such as keeping track of environmental conditions, patterns of pixels, and frame differencing or background subtraction, I found interesting is the example of the use of a “telecentric” lens to improve the performance of certain kinds of shape-based or size-based object recognition algorithms. I have always known that every algorithm in any computer system has a distinct role. However reading about how this lens has such a meticulous and specific task in detail has taught me the importance of each algorithm in the larger scale of aiming to achieve a successful, computer vision.

Personally, a computer’s vision capacity for tracking and surveillance can be quite effective in the use of interactive art, especially when it comes to immersive experiences. Its ability to “modify physical conditions” and capturing things such as movement or gestures can be useful to create responses to human actions which can be explore in immersive installations. Hence, like many immersive experiences, these responsive systems would allow participants to enhance the value and experience, conveying a more complex and meaningful kind of interactive artwork.

I hadn’t learned much about computer vision before reading this article, except it was about enabling computers to “see” and understand visual data. What struck me most was the irony in how computer vision compares to human vision. Computers can be unbelievably precise, catching patterns, colors, or tiny movements that a human eye might overlook. But they can also completely miss things we find easy, like recognizing a familiar face in poor lighting or spotting an object that’s just been turned around. To me, that contrast really shows how naturally flexible our own vision is, while computer vision feels much more rigid and depends on whether the physical conditions it was trained for are perfectly reproduced. I came to see how important it is to design the physical environment when working with computer vision so that the system can function more effectively – for instance, arranging lighting, colors, and contrasts to make key features easily detectable.

As I thought more about computer vision, I realized that helping a computer “see” is not just about coding; it’s also about choosing the right technique for the specific task. Methods like color tracking or motion detection can work really well, but they each have their weak spots. For instance, a color tracker could get confused if the background shares the same shade, and a motion detector could be thrown off by something moving in the background that has nothing to do with the task. It made me see how much depends on matching the method to the situation; otherwise, the results fall apart.

When it comes to interactive art, computer vision’s ability to track and even surveil people feels both fascinating and a bit worrying. Tracking can make an artwork feel alive—it follows your gestures and responds in ways that draw you in. But surveillance goes further than that. It suggests being constantly observed, maybe even recorded, without realizing it. This is where the concern for privacy creeps in. One artwork that shows this really well is Rafael Lozano-Hemmer’s Surface Tension. In this piece, a large projected human eye follows you around the room. At first, it feels playful and interactive, like the artwork is aware of you, but the longer you stay, the more uncomfortable it becomes. I guess this tension is what makes interactive art with computer vision so compelling, because it not only provides us with an engaging experience but also pushes us to reflect on the aspect of being monitored.

When I was reading ‘Computer Vision for Artists and Designers’, one thing that stood out to me was how computer vision is so different from human vision. For us, seeing feels natural , we can look at a scene and instantly recognize people, objects, emotions, or even context. But computers don’t “see” that way. For them, an image is just a bunch of pixels with numbers. They need step-by-step methods to figure out what’s moving, what belongs in the background, or what part of the picture matters.

The reading showed me some basic techniques that help computers track what we want. For example, frame differencing looks at what’s changed from one frame to the next, background subtraction compares the scene to a saved “empty” version to spot people, and brightness thresholding picks out objects based on how light or dark they are compared to the background. These sound simple, but they can be powerful if the physical setup is right like having strong contrast or good lighting. I liked how the article talks about the environment matters just as much as the code.

Thinking about how this connects to interactive art, I can see both exciting and uneasy sides. On one hand, artists can use tracking to make playful or immersive experiences, like games that respond to your body or installations that react to your movements. That feels fun, creative, and even magical. But at the same time, the same tracking tools can be used for surveillance, like watching people without their consent or profiling them. That tension makes interactive art more thought-provoking, because it forces us to see how technology can be both empowering and controlling.

For me, this makes computer vision in art feel very alive , it’s not just about coding tricks, but about what message the artist is trying to send and how it makes us reflect on being “seen” by machines.