Concept:

In this series of exercises, we explored how Arduino and p5.js can talk to each other through serial communication. Each exercise focused on a different direction of data flow. First, Arduino sent information to p5.js. Then we switched it so p5.js controlled something on the Arduino. Finally, we combined both directions to create a full bi‑directional system. Doing these three tasks helped us understand how physical sensors and digital visuals can work together to create interactive experiences.

For the first exercise, we made a sketch where a circle in p5 moves left and right based on a potentiometer connected to Arduino. The potentiometer is the only sensor being used here, and its value controls the horizontal position of the circle while the circle stays in the middle of the screen vertically. On the Arduino side, the potentiometer value is read and sent through serial communication. On the p5 side, that value is read from the serial port and used to control the x position of the circle.

For the second exercise, we made a sketch where p5 controls the brightness of an LED on Arduino. Instead of Arduino sending data to p5, p5 sends a value to Arduino. I used a slider in p5, and moving that slider changed the brightness of the LED. The slider sends a value through the serial port, and Arduino reads that value and uses analogWrite() to control the LED brightness. Since brightness needs a gradual range, the LED had to be connected to a PWM pin.

For the third exercise, we combined both directions into one interactive system. We used the gravity‑wind example from class and connected it to both Arduino and p5.js. The potentiometer controlled the wind force in the p5 sketch, so turning it left or right pushed the falling ball in that direction. At the same time, p5 sent a message back to Arduino every time the ball hit the bottom of the screen. This made the LED blink with each bounce, creating a small physical reaction that matched the animation. Seeing the LED flash at the exact moment the ball hit the ground made the connection between the screen and the hardware feel much stronger. This exercise showed how both sides can respond to each other in real time.

Code:

P5 exercise 1: 

P5 exercise 2:

P5 exercise 3:

Arduino Github Link Exercise 1: https://github.com/mhraalnuaimi/exercise1week11/blob/main/W11..01_serial_simple_potentiometer.ino 

Arduino Github Link Exercise 2: https://github.com/mhraalnuaimi/exercise2week11/blob/main/W11_02_Bidirectional_Com.ino 

Arduino Github Link Exercise 3:  https://github.com/mhraalnuaimi/exercise3week11/blob/main/exercise3week11.ino 

 

Setup:

Exercise 1:

Exercise 2:

Exercise 3: 

Demonstration:

Exercise 1:

Exercise 2: 

Exercise 3: 

Schematic:

Exercise 1:

Exercise 2:

Exercise 3:

Process:  

During these exercises, we followed the same steps for each project: wiring the components, writing the Arduino code, and then connecting everything to p5.js using WebSerial. For Exercise 1, we wired a potentiometer and tested the analog readings in the serial monitor before using them in p5. In Exercise 2, we focused on sending values from p5 to Arduino, so we tested the slider and made sure the LED responded smoothly. Exercise 3 was the most detailed because it used both directions of communication. We had to make sure the potentiometer values were clean, the wind force felt natural, and the LED blinked at the right moment. We also learned that adding a newline at the end of each serial message made the communication much more stable. Overall, the process helped us understand how to connect physical sensors with digital visuals step by step.

 

Code We Are Proud Of:

Code Snippet:

port.write("1");
setTimeout(() => port.write("0"), 100);

This is the part of the code we are most proud of because it shows the moment when p5.js talks back to Arduino. When the ball hits the bottom of the screen, p5 sends a “1” to turn the LED on and then sends a “0” to turn it off again. This creates a quick flash that matches the bounce.

 

Reflection and Areas of Improvement:

Working through these three exercises helped us understand how Arduino and p5.js can communicate in different ways. In Exercise 1, we learned how to read an analog value from Arduino and use it to control something in p5.js. In Exercise 2, we learned how p5.js can send values back to Arduino to control hardware like an LED. In Exercise 3, we combined both directions and created a full interactive loop where both sides respond to each other. This final exercise felt like the most complete example of how serial communication can be used in creative projects. If we continued building on these ideas, we could make more complex interactions such as small games, musical tools, or installations that react to multiple sensors. Overall, these exercises helped us build a strong understanding of serial communication and how physical and digital elements can work together. 

If we were to improve these exercises, we would try adding more sensors or combining different types of inputs to make the interactions more interesting. For example, we could add buttons, sound sensors, or even an ultrasonic sensor to create more complex reactions in p5. We could also improve the visuals by adding animations or smoother movement to the ball. Another improvement would be organizing the code better by separating the serial functions from the physics code to make everything easier to read. These changes would help make the projects feel more polished and closer to real interactive installations.

 

References:

All the concepts we used in these exercises came from the Week 11.1 and Week 11.2 lecture slides. These slides explained how serial communication works, how to use WebSerial in p5.js, and how to send and receive data between Arduino and p5.  

For my final project, I am creating a physically interactive maze game that uses both Arduino and P5.js. So I decided to pick minnie mouse and mickey mouse as my two characters. The idea is to guide minnie mouse through a maze using two physical potentiometers instead of a keyboard or mouse. The player’s goal is to move minnie mouse from the start of the maze to the end, where mickey mouse is waiting.

The interaction works in a simple cycle of listening, thinking, and responding. The Arduino will be the “listener” because it reads the positions of the two potentiometers. One knob controls left andright movement, and the other controls up and down movement. When the player turns the knobs, Arduino senses the changes and sends those values to P5.js. P5. will be the “thinker,” because it takes those values and turns them into movement on the screen. The game then responds by moving the character in real time and showing whether the player is controlling minnie mouse in staying inside the maze or hitting the walls.

The maze itself will be drawn in P5 using simple shapes or a custom layout. I will have a start screen and instructions screen. The character will move smoothly through the pathways, and basic collision detection will prevent it from passing through walls. When the player reaches the goal area, the game will display a small celebration animation or visual cue to show that the objective has been completed. The experience is meant to feel playful, fun and slightly challenging, since the player must learn how to control movement using physical knobs instead of controlling it with the laptop. I will probably take photos of minnie mouse and mickey mouse of the internet and use them as my characters.

Reading Design Meets Disability made me think differently about how society treats disability devices. One part that stayed with me says that trying to hide these devices can show “a lack of self confidence that can communicate an implied shame.” This made sense to me because I believe disability devices should be shown proudly. There is nothing to hide, and people should feel free to embrace what makes them unique. The reading helped me understand that hiding something can sometimes send a negative message, even if people do not mean it that way.

Another idea that surprised me was how design for disability can inspire mainstream design. The text explains how the Eames leg splint influenced famous furniture. I never expected a medical object to shape everyday design. This showed me that disability centered design can be creative and important, not only functional.

The reading also changed how I think about the look of medical devices. When Aimee Mullins chooses “off the chart glamorous” prosthetics, it shows how fashion can help people feel confident. If I had to wear a hearing aid or prosthetic, I would want it to be unique and fashionable too. Something that stands out in a good way and can influence others to do the same. This is why I think fashion designers, especially designer brands, should help create these devices. It would make people feel included and inspire many other small businesses and brands globally.

Overall, the reading taught me that disability and design do not need to focus on hiding. They can focus on expression, creativity and how each person shows their own personality with something so unique.

Concept:

In this assignment, we had to create a musical instrument using digital and analog sensors. We used push buttons as our digital sensors and a potentiometer as our analog sensor. We then decided to create a mini piano-like device that plays the four basic piano notes C, D, E, and F, and allows the user to adjust the pitch of these notes. In this project, there are four push buttons, each assigned to one note that only plays when the button is pressed, and a potentiometer that changes the pitch of the notes when it is turned.

Code:

Arduino File on GitHub

Setup:

Mariam’s Setup

Mhara’s Setup

 

Demonstration:

Mhara’s video demo:

Mariam’s video demo:

Digital Circuit:

Schematic:

Process:

In the process of this assignment, we decided to combine four buttons (digital) with one potentiometer (analog) to control a piezo buzzer. Each button plays a different note, and the potentiometer slightly adjusts the pitch so the sound changes depending on how much it’s turned. We worked together on the idea and the wiring, but we divided the coding so each of us focused on one part. Mariam handled the digital part (the buttons and the notes), and Mhara worked on the analog part (the potentiometer and the pitch control). After both parts were working separately, we combined them into one full sketch of code.

We then tested the circuit in Tinkercad to make sure all the wiring and logic of the code were correct. This helped us confirm that the buttons were reading properly and that the potentiometer was giving smooth values. Running it in Tinkercad also made it easier to fix small mistakes before trying it on the physical Arduino board.

At first, the audio wasn’t changing when the potentiometer was turned because the mapping was happening after the tone was already being played, so we rearranged the order of the code and that finally made the pitch respond. After that, the sound became too noisy and robotic, so we added a small adjustment range (90 – 105) to each note to make the pitch change smoother and less harsh.

 

Code Snippets:

While building the project, there were a couple of code snippets that stood out to us because they played an important role in making the instrument work the way we wanted it to. 

tone(buzzerPin, noteC * map(sensorValue, 0, 1023, 90, 105) / 100);

This was the part we were most proud of because it solved the “robotic” and “noisy” sound problem. Instead of letting the potentiometer completely change the note, we used a small adjustment (90-150) to bend the pitch smoothly. And this showed how the digital and analog inputs can work together in one line of code. 

 

Another part of the code is :

pitch = map(sensorValue, 0, 1023, 200, 2000);

This line shows how the analog input (the potentiometer) controls the sound. It takes the raw value from 0-1023 and maps it into a pitch range that the buzzer can actually play. This was important because the potentiometer originally wasn’t affecting the sound at all, and fixing the order of the code made this line finally work the way we wanted it to. 

Areas of Improvement and Reflection:

After completing this assignment, we were able to learn and explore different sensors and sounds. It was easy and smooth to work as a pair, as each person focused on one part and then we combined our work together. As for areas of improvement, we could make the sound of the notes smoother and more musical, since it still sounds slightly robotic, or add more notes to make it closer to a real piano. Another idea is to implement other sensors, such as an ultrasonic sensor, to play different notes or even melodies based on motion or distance. Working with audio and sensors is a fun part of Arduino, and it allows us to create many different ideas for various purposes. Overall, we are satisfied with our final outcome and the entire process of this project.

 

References:

Looked back at Week 10 slides about sound to recap what we learned.

Reviewed specific code concepts using the Arduino documentation:

https://docs.arduino.cc/language-reference/en/functions/math/map/ 

• How we used it: We used this to convert the potentiometer’s range into a smaller pitch-adjustment range that works smoothly with the buzzer.

https://docs.arduino.cc/language-reference/en/functions/advanced-io/tone/ 

• How we used it: We used this page to understand how the tone() function works and how to send different frequencies to the buzzer. 

https://docs.arduino.cc/built-in-examples/digital/toneMelody/ 

• How we used it: We looked at this example to understand how notes from pitches.h are used and how tone() can be combined with different frequencies to create musical sounds.

Ai usage:  Used ChatGPT to help navigate and resolve a major issue where the tones sounded too robotic and noisy. From this, we learned that using the map() function with a smaller range for each note helps create smoother, more controlled pitch changes.

When I thought about touchscreens before this assignment, I always felt they were fun and easy to use. I liked exploring things by touching the screen instead of using buttons or a mouse. Because of that, I assumed touchscreens were already the best version of future technology. After reading the texts, I started to notice how limited screens actually are. They only let me use one finger, even though my hands and body can do much more. This made me think about how technology does not really use our full abilities.

One idea that made me think was how the author described touchscreens as flat and numb. I never thought about how everything feels the same when I touch my phone. There is no real physical feedback. When I read that, I realized that I also feel limited by screens and I hope technology develops into something more than just glass surfaces. It made me wonder what it would feel like if my phone could respond physically, not just visually.

The readings also made me think about creativity. I believe creativity can be fully digital, like movies, where you do not need to touch anything to understand or enjoy it. But at the same time, I noticed that when I work on physical computing projects in class, using sensors and real materials feels more engaging. It uses more of my body, not just my eyes.

Another part that stayed with me was the idea of children using iPads. I think it can be bad because of radiation, but it can also be very educational if used the right way. The reading made me think more deeply about how screens might affect development, especially if kids only interact with flat surfaces.

Overall, these readings made me question my assumptions about future technology. I used to imagine better screens, but now I imagine tools that involve more of the body. It made me think that maybe the future should not be limited to touchscreens, and that we should explore new ways of interacting that feel more natural and physical.

My concept: 

For this week’s assignment, I worked on a small circuit that uses a button and a potentiometer to control two LEDs. The button works as a digital input, so the LED connected to it only turns fully on or fully off. The potentiometer is an analog input, so it gives a range of values, and that lets the second LED fade smoothly instead of switching instantly. Seeing both of them together helped me understand the difference between digital and analog in a very clear way. One is fixed, and the other changes gradually.

Code Snippet I’m Proud Of:

int potValue = analogRead(potPin);
int brightness = potValue / 4;
analogWrite(fadeLed, brightness);

This part made the most sense to me once I understood what PWM actually does just like how i learned on the slides. The potentiometer gives a value from 0 to 1023, but the LED only uses 0 to 255.  When I saw the LED fade smoothly as I turned the knob, it finally clicked for me how analog control works.

Process

I started this assignment by deciding which inputs and outputs I wanted to use. Since the goal was to work with both analog and digital inputs, I chose a pushbutton for the digital part and a potentiometer for the analog part. I wanted each one to control a different LED so I could clearly see the difference between the two types of signals.

I began by setting up the breadboard and making sure it had power. I connected the 5V pin from the Arduino to the positive rail and the GND pin to the negative rail. After that, I wired the button to pin 2 and added the 10k resistor to ground so it could work as a pull‑down. Then I connected the potentiometer to A1 and made sure the middle pin was going to the analog input. Once both inputs were connected, I added the two LEDs with 330 resistors to protect them.

At first, I tried to test everything on the physical Arduino, but the board started acting in a way that it wasn’t working and connecting to the laptop and kept shutting down, the green light would blink for a second and then everything will go off, and I wasn’t able to find the cable option on the ports shown to connect the code with my arduino, so that’s why it wasn’t working. After a lot of troubleshooting, I realized the problem was not my code or my wiring. The board itself was not responding properly. Because of that, I moved the project to Tinkercad so I could finish the assignment without dealing with hardware issues I could not fix. In Tinkercad, the circuit worked the way it was supposed to, and it helped me understand the logic more clearly.

My tinkercad:

https://www.tinkercad.com/things/b5J0eHZInWx/editel?lessonid=EFU6PEHIXGFUR1J&projectid=OGK4Q7VL20FZRV9&collectionid=undefined&title=Editing%20Components&sharecode=UdELcMJJ9AZbknNHQbrLb1glfjri4FwRHka6vCkfr5U

Sketch:

My circuit:

My code:

int buttonPin = 2;     // the button
int ledPin = 13;       // the digital LED
int fadeLed = 11;      // the fading LED
int potPin = A1;       // the potentiometer

int buttonState = 0;   // to store what the button is reading
int potValue = 0;      // to store what the potentiometer is reading
int brightness = 0;    // to store LED brightness

// pinMode( tells the Arduino how each pin will be used)
void setup() {
  pinMode(buttonPin, INPUT); //the button is an INPUT because I’m reading from it
  pinMode(ledPin, OUTPUT); // the LEDs are OUTPUTS because the Arduino controls them
  pinMode(fadeLed, OUTPUT); //this runs once when the Arduino starts
}

void loop() {

  buttonState = digitalRead(buttonPin); // this checks if the button is pressed or not, t will be HIGH when pressed and LOW when not pressed


// if the button is pressed this means the LED on pin 13 turns on
// if the button is not pressed this means LED turns off

This is a simple if/else condition.
  if (buttonState == HIGH) {
    digitalWrite(ledPin, HIGH);
  } else {
    digitalWrite(ledPin, LOW);
  }

  // the pot gives a value between 0 and 1023
// this depends on how much I turn the knob

// I store it in potValue so I can use it for brightness
  potValue = analogRead(potPin);

  //analogWrite() only accepts values from 0 to 255 so dividing by 4 converts the 0–1023 range into 0–255
  brightness = potValue / 4;

//this sends a PWM signal to pin 11,the LED brightness changes smoothly based on the pot
// the higher pot value means brighter LED
  analogWrite(fadeLed, brightness);
}

Reflection / Future

This project helped me understand analog and digital inputs in a more real way. I already knew the definitions, but seeing how each LED reacted made it easier to get it. The digital input was very straightforward because the LED only turned on or off. The analog input felt more interesting because the brightness changed slowly when I turned the potentiometer. Using both at the same time made me feel more comfortable with how the Arduino reads different signals.

I also learned a lot about wiring and how small mistakes can mess up the whole circuit. I kept running into problems on the breadboard, and even when the wiring looked right, things still didn’t work. When the physical board stopped responding completely, I had to switch to Tinkercad. Even though that was frustrating, it helped me focus on the logic instead of fighting with hardware issues. It also showed me how important it is to check every connection carefully.

In the future, I want to try using more sensors and making the interactions more interesting. I also want to keep my wiring cleaner because it makes debugging so much easier. Now that I understand the basics better, I feel more ready to try bigger projects and see how these components can work together in different ways.

The first reading made me think a lot about how physical computing projects repeat every year. At first, I thought it meant people were running out of ideas, but the reading made me see it differently. I realized that people repeat projects because they get inspired by what others make, not because they lack creativity. I do not think ideas are limited, but I do think people naturally follow things they find cool or interesting. For me, it is okay to redo a project if you add your own twist, but I still prefer coming up with something new. If I worked hard on an idea, I would not want someone copying it too closely. The reading also made me understand that originality is not always about doing something completely new. Sometimes it is about how you change the idea, how you design it, and how you make it feel different from the rest. That part made me think more about how I approach my own projects in class.

The second reading made me think about how interactive art works and how much control the artist should have. I agree that artists should not tell the audience what to think, because everyone sees things in their own way. If you enjoy what you are making, you do not need other people’s opinions to change your message. I also liked the idea that the audience completes the artwork through their actions. It made me realize that interactive art is not just about the object or the device. It is also about how people move, react, and explore it. The reading made me think differently about designing interactive pieces, because it showed me that the audience’s reaction is part of the artwork itself. Both readings made me see that in physical computing and interactive art, the designer does not need to control everything. Sometimes the best part is letting people explore freely and create their own experience.

When I read Norman’s idea that attractive things “work better,” I realized it actually matches how I react to design in my everyday life. I do feel more drawn to things that look nice, whether it is a cute device, a clean app layout, or even good packaging. When something looks appealing, I automatically feel more positive toward it, and I am more patient when it has small issues. At the same time, I do not think beauty should be more important than usability. I believe designers need to balance both, because something that looks good but does not function well is frustrating, and something that works well but looks boring is not enjoyable either. His point made sense to me, but I also think he focuses a lot on emotion, and not every situation works that way.

The reading about Margaret Hamilton made me think about how different the tech world is today compared to her time. I personally have not felt underestimated in technical classes, and I do not feel like there is discrimination toward women in the spaces I am in now. But I know that fifty years ago it would have been a very different experience, and her story shows how much pressure she worked under. It also connects to Norman’s idea about emotion. She had to work in a very stressful environment, and that pressure probably forced her to be extremely focused and careful, which is what Norman describes when he talks about how negative emotions narrow thinking. Her story made me think about how serious and impactful technical work can be, and how much responsibility goes into writing code that other people depend on.

My concept

For week 8’s assignment, we were asked to create a switch that uses the human body to complete a circuit, but without using our hands. I wanted something simple but still interesting, so I decided to build a foil‑based touch switch that activates an LED when my elbow connects two pieces of aluminum foil. The idea behind my switch is that the body can act as a conductor: when the two foil pads are separated, the circuit is open, and when my elbow touches both at the same time, the circuit closes and sends a HIGH signal to the Arduino. I liked this idea because it felt playful and intuitive,  instead of pressing a button, I’m using a part of my body that normally isn’t used for electronics. Once everything was wired correctly, the LED lighting up from just a touch of foil felt surprisingly satisfying.

The demo and setup

Video: IMG_3331

Photo: https://intro.nyuadim.com/wp-content/uploads/2026/04/IMG_3322.heic

Photo:  https://intro.nyuadim.com/wp-content/uploads/2026/04/IMG_3319.heic

The sketch: https://intro.nyuadim.com/wp-content/uploads/2026/04/IMG_3332.heic

The code I’m proud of 

The part of the code I’m most proud of is the core logic that actually makes the switch work. Even though it looks simple, this was the section I spent the most time understanding and debugging. It reads the input from the foil and decides whether the LED should turn on or off. Once the wiring was correct, this logic worked instantly and reliably.

int state = digitalRead(switchPin);   

if (state == HIGH) {                  
  digitalWrite(ledPin, HIGH);         
} else {                              
  digitalWrite(ledPin, LOW);          
}

This snippet represents the entire interaction: the Arduino constantly checks the state of the foil switch, and the LED responds in real time. After all the debugging I went through, seeing this simple logic finally work felt incredibly rewarding.

 

Github link: https://github.com/mhraalnuaimi/week8assignment/blob/main/foil_switch.ino 

Problems I faced

This assignment ended up being much more challenging than I expected, not because of the code, but because of the wiring. At first, nothing happened when I touched the foil, the LED stayed off no matter what I did. I kept adjusting the foil, retaping wires, and trying different ways of touching it, but the Arduino wasn’t detecting anything. I assumed the foil wasn’t conductive enough or that my body wasn’t completing the circuit properly.

Eventually, I started debugging step‑by‑step. The most important test was touching the bare wire from pin 2 directly to the 5V pin. When I did that, the LED turned on immediately. That moment told me that the code, the LED, and the Arduino were all working perfectly. The problem had to be somewhere in the breadboard wiring.

After more testing, I discovered the real issue: the second GND wire connected to the resistor row was pulling the signal LOW permanently. Because of that, pin 2 could never go HIGH, even when the foil was touched. Removing that incorrect GND connection instantly fixed the problem. Once the wiring was corrected, the foil switch worked exactly the way it was supposed to.

I also rebuilt the foil pads so that the bare metal of the wire touched the bare foil directly, which made the connection much more reliable. After that, the LED responded perfectly every time my elbow bridged the two foil pieces.

Reflection 

This assignment taught me a lot about how sensitive breadboard wiring can be. I realized that most Arduino problems aren’t caused by the code, they’re caused by one wire being in the wrong row or one resistor being connected incorrectly. Debugging forced me to slow down and test each part of the circuit logically instead of guessing. The moment I isolated the issue and saw the LED turn on from the foil switch felt incredibly rewarding.

I also enjoyed experimenting with different ways of activating the switch, like using a metal pen instead of my elbow. Overall, I’m proud of how much I learned from this process. Even though it was frustrating at times, it made me more confident in reading circuits, understanding pull‑down behavior, and debugging systematically. Next time, I’ll double‑check my wiring before assuming the code is wrong, it would have saved me a lot of time.

References 

Arduino Documentation: digitalRead()

https://docs.arduino.cc/language-reference/en/functions/digital-io/digitalread/ I used this page to understand how the Arduino interprets HIGH and LOW signals from my foil switch.

Arduino Documentation: pinMode()

https://docs.arduino.cc/language-reference/en/functions/digital-io/pinmode/ I used this reference to confirm how to correctly set pin 2 as an INPUT so it could read the foil connection.

Arduino Documentation: Digital Pins

https://docs.arduino.cc/learn/microcontrollers/digital-pins I used this explanation to understand how input pins behave electrically, especially how they float without a proper pull‑down or pull‑up resistor.

Arduino Tutorial: Digital Input Pull-Up

https://docs.arduino.cc/tutorials/generic/digital-input-pullup I used this tutorial to compare my physical pull‑down resistor setup with Arduino’s internal pull‑up option and understand why my circuit needed stabilization.

Class slides

I used the class slides to review how switches work, how breadboard rows connect, and where resistors should be placed in a circuit.

Arduino cheat sheet

I used the cheat sheet to quickly double‑check syntax for digitalRead(), digitalWrite(), and pinMode() while writing and editing my code.

AI  usage debugging (ChatGPT)

I used AI to help me debug the circuit step‑by‑step, especially to isolate the issue with the misplaced GND wire and confirm that the code itself was working correctly.

My overall concept:

My project is an interactive game called Boba Builder, where the player gets to create their own custom bubble tea drink. I wanted the game to feel fun and give the user a cute, customizable experience, almost like a small digital cafe where you can design a drink however you want. The idea actually started because I was craving matcha, and at first I wanted to make a matcha‑themed game. But then I realized matcha doesn’t have many color or topping variations since it’s always green, so it didn’t feel very customizable. That made me think about other drinks, and then I remembered how popular boba tea was around 2020-2022 during the COVID era. I mean, it’s still popular now, but that was the time when it really became a trend. I liked how many different combinations you can make in real life, and that inspired me to turn it into a game where players can mix and match their own drink.

The main goal of my project was to make the player feel like they are actually building something step by step. Each screen represents a different part of the drink‑making process, and the choices the player makes show up inside the cup. I wanted the final drink to feel personal, like something the player actually created, and I liked the idea that every person could end up with a completely different drink. The game doesn’t have winning or losing; it’s more about creativity, enjoying the process, and having a fun little experience.

Final Project: 

How My Project Works: 

The entire game I built uses the same coding ideas we learned in class, which made it easier for me to understand how to structure everything. My project works using a state system in p5.js. This means the game changes screens depending on what the player chooses. For example, the game starts on the start screen, then moves to the tea screen, then the boba screen, then the ice screen, and so on. Each screen has its own buttons that let the player pick what they want to add to their drink. When the player clicks a button, the game updates a variable like chosenTea, chosenBoba, or chosenIce. These variables are then used inside my drawCup() function, which updates the cup and shows the player’s choices as they build their drink.

if (state === "start") {
  drawStartScreen();
} else if (state === "tea") {
  drawTeaScreen();
} else if (state === "bubbles") {
  drawBobaScreen();
} else if (state === "ice") {
  drawIceScreen();
} else if (state === "straw") {
  drawStrawScreen();
} else if (state === "color") {
  drawColorScreen();
} else if (state === "finished") {
  drawFinalScreen();
}

I also used object‑oriented programming to create my buttons. I made two classes: a Button class for rectangle buttons and a RoundButton class for circle buttons. Each button has its own position, size, color, and label. Both classes also have a clicked() function that checks if the player pressed the button. This helped me reuse the same code for all my buttons instead of rewriting it over and over. It made my project much more organized and easier to manage.

class Button {
  constructor(x, y, w, h, fillColor, textColor, txt) {
    this.x = x;
    this.y = y;
    this.w = w;
    this.h = h;
    this.fillColor = fillColor;
    this.textColor = textColor;
    this.text = txt;
  }

  draw() {
    fill(this.fillColor);
    rect(this.x, this.y, this.w, this.h, 30);
    fill(this.textColor);
    textSize(width * 0.035);
    text(this.text, this.x, this.y);
  }

  clicked() {
    return (
      mouseX > this.x - this.w / 2 &&
      mouseX < this.x + this.w / 2 &&
      mouseY > this.y - this.h / 2 &&
      mouseY < this.y + this.h / 2
    );
  }
}

The game also uses sound effects and background music. The background music plays throughout the whole game, and when the player pours tea, the pouring sound plays. When the pouring sound finishes, the game automatically moves to the next screen using pour.onended(nextState);. I also added sounds for boba, ice, and other actions to make the game feel more interactive and satisfying. At the end of the game, the player sees their final drink with all the choices they made.

What I’m Proud Of:

I’m really proud of how the whole game feels like a real drink‑making experience. The cup updates step by step, and the player can see their drink change as they make choices. I’m also proud that I figured out the back button issue. Now, on every screen, the player can go back to the previous page without breaking the game, which took a lot of testing and fixing. I’m also proud of the visuals I drew in Procreate. I made the start‑screen background, the toppings, and the decorations myself, and I think they make the game look cute and fun.

Another thing I’m proud of is the button system I created. I made a separate buttons.js file and used classes to organize all my buttons. This made my code much cleaner and helped me understand object‑oriented programming better. I’m also proud of how I used sound effects to make the game feel more real and less boring. The pouring sound, the drip sound, and the ice sound all add to the experience and make the game more satisfying to play.

I’m also proud that I solved some difficult bugs. The back button and the lag issues were really frustrating, but I kept trying different things until I fixed them. It felt good to finally get everything working the way I wanted.

Areas of Improvement & Problems I Faced:

One area I want to improve is how the layout works on different screen sizes. I used windowWidth and windowHeight to make the game responsive, but sometimes the buttons or text still look a little off on very small or very large screens. In the future, I want to create a better scaling system so everything stays in the right place no matter what device the player uses, even on phones.

I also had problems with the back button. Sometimes it didn’t reset the right variables, so old choices stayed on the screen. Other times, the game lagged because something was being recreated inside the draw() function instead of only running once in setup(). These issues took a long time to figure out, and I had to test many different things before I finally fixed them.

Another challenge was making sure the cup updated correctly with all the player’s choices. I had to keep track of many variables and make sure they all worked together without breaking anything. It was confusing at first, but once I organized everything and cleaned up my code, it became much easier to manage.

References: 

– Pouring sound:  https://freesound.org/people/piotrkier/sounds/700153/ 

• I used this sound for when the tea pours into the cup.

– Drip sound:  https://freesound.org/people/Neotone/sounds/75345/ 

• This sound plays when the player chooses boba or a color.

– Ice sound:  https://freesound.org/people/giddster/sounds/386431/ 

• This sound is used when the player adds ice to their drink.

– Background Music: https://freesound.org/people/Mrthenoronha/sounds/370293/ 

• I used this as the soft background music that plays during the whole game.

– Audio Editing Tool: https://clideo.com/editor/ 

• I used this website to trim and edit my audio files so they fit better in the game.

– Font Used: https://fonts.google.com/specimen/Ribeye+Marrow 

• This is the custom font I used for the text in my project.

– p5.js reference: https://p5js.org/reference/p5.MediaElement/onended/ 

• I used this p5 reference to learn how the onended() function works. This helped me understand how to make the game move to the next screen after the pouring sound finishes.

– Drawings:  

• I used Procreate to draw the visuals for my project, including the start background and the toppings. I created each drawing myself and exported them as PNG files so I could use them for my game.

Ai usage: 

• For my project, I mainly used ChatGPT to help me understand and fix problems that were confusing or hard to figure out on my own. One issue I had was that when I changed the size or position of something in my sketch, other parts of the layout sometimes reacted in ways I didn’t expect, especially because I was using a lot of percentage‑based values like width * 0.5 or height * 0.7. ChatGPT helped me understand how p5.js handles screen sizes and why certain numbers can affect the spacing of different elements. I also used ChatGPT to understand why my instructions text wasn’t breaking into separate lines and it was written in a way that wasn’t aesthetically appealing. It explained how the \n symbol works in p5.js and how text alignment affects multi‑line text, which helped me format my instructions correctly. Another major problem was my back button. Sometimes it took me to the wrong screen, sometimes it kept old choices even when restarting th whole p5 game, and sometimes it even made the whole game lag. ChatGPT helped me understand that this can happen if the order of resetting variables and changing states is wrong, or if something is being recreated inside the draw() function when it should only happen once in setup(). After learning this, I reorganized my code and fixed the issue. ChatGPT also helped me understand why my game lagged at certain moments by explaining that loading images or creating new objects inside the main loop can slow everything down. Finally, I asked ChatGPT to explain how the onended() function works for sounds, which helped me understand why I needed pour.onended(nextState); for my tea‑pouring animation. All the coding, design, and decisions in my project were done by me; ChatGPT only helped me understand confusing parts and figure out why certain things weren’t working the way I expected.