Concept:

I love dancing, so I wanted to create a switch that incorporates my hobby by doing the Stanky Leg! To do this, I used copper tape and attached strips to my knees. As I move and dance, my legs bend and the copper tapes on each knee come into contact. When they touch, the circuit is completed, which activates the switch and lights up the LED. This way, the LED lights up through the movement of dance, making it both interactive and fun.

https://drive.google.com/file/d/1TfbptN2TEvhUywdUC8JOCoeZR8rrbgjd/view?usp=sharing

Challenges:

It turned out to be more challenging than I expected because the wires had to maintain solid contact with the copper tape. However, as I moved my legs while dancing, the tape started to come loose, which caused the connection between the wire and the copper tape to break, disrupting the circuit.

This reading discusses the valuable contributions of Margeret Hamilton in the Apollo space mission and the field of software engineering. It is quite impressive to note that Hamilton was a working mother who worked days and nights to formulate the very software for the Apollo space missions. She faced deep skepticism and bias as a woman working in male-dominated fields, but she earned her righteous place among the others as a pioneer in the field of software engineering. It was interesting to see how the Apollo 8 mission astronauts once accidentally wiped out the navigational data, and how effectively she solved the problem with her team. Hamilton’s story inspired me in reflecting upon her values and mission as a woman in the male-dominated world of engineering and technology. She inspires everyone to step outside their comfort zones and experiment with curiosity. Her duality as a mother and a software engineer tells us that life can never give us setbacks, and it is up to us to overcome them. She inspires me to adopt her tactics of problem solving and team management and leadership in my life as well, adapting to these values and visions in the field of design and technology.

This reading by Don Norman focuses on the concept of aesthetics influencing an objects’ useability. Norman argues that aesthetic appeal can positively influence a person’s user experience. It can even help cover up minor errors and discrepancies in the objects’ useability. From “Coffee Pots for Masochists” to colourful TV screens, the beauty of everyday items can influence cognition and overcome minor misunderstandings. This reading made me think long and hard about all of the objects I use on a day-to-day basis, starting from the very iPad Pro I’m typing this blog post on, to the oversized cute coffee mug next to me. Is the mug very large; do I even need that much coffee? Probably not. But is the mug very pretty to look at; does it fit my aesthetics perfectly? Oh yes. Norman talks about the colourful TV screens, how colour was merely a thing of beauty in the already perfectly functional screens. This made me think of how we, as students, always design powerpoint presentations, or any sort of display. While the text to get the point across is visibly apparent, we also focus on the aesthetics and how appealing it is to our audience. However, too much “beautifying” can take away from the display’s message; and too little can’t capture the attention of our audience. The fine line between beauty and functionality is exactly what Norman proposes we depend on for the perfect formula in creating cool things.

Link to the Sketch: https://editor.p5js.org/izza.t/full/V9Mv_WERI

For my midterm, I decided to do a spin-off of a classic maze that is also heavily inspired by 2 other things I love: mystery and cats. The story of the game involves an archeologist exploring an abandoned tomb that is said to hold a large treasure with their cat. Suddenly, something spooks the cats and it runs off into the tomb. It is then revealed that the tomb is like a maze, and the user must navigate through it. The catch? It’s pitch black apart from the small light from their flashlight and there are booby traps in certain parts of the maze like a mummy, beetles, and a snake that will cause the player to have to restart if the player collides into them.

The game works by showing a start screen that explains the situation and what keys to use to navigate the game. The player uses the arrow keys to navigate up, down, left, and right through the maze and can use the ‘C’ key to call for their cat and hear it’s meow which expands their flashlight radius momentarily (almost like a power up). This feature does have a cooldown feature that is displayed at the top. The user must navigate through the maze to the end to win and find both their cat and the lost treasure. They must do so without triggering any of the booby traps and dealing with all of the dead ends in the maze.

The maze itself took the longest time to create, almost an entire day, as it all had to be hardcoded using an image I had found of tomb-like stone walls online. Then, creating the flashlight like circle around the player and making sure that only pieces of the maze that are within that circle are displayed required the use of masking. This required me to use a new function called drawingContext which unlocks more features of the canvas in p5js and allowed me to do that. The code for which I’m very proud of and can be seen below.

class Maze {
  constructor() {
    this.walls = [
      // Outer boundaries (these are always visible)
      {x: 75,    y: 0,    w: 1200, h: 30},   // Top
      {x: 0,    y: 570,  w: 1200, h: 30},   // Bottom
      {x: 0,    y: 0,    w: 30,    h: 600}, // Left
      {x: 970, y: 0,    w: 30,    h: 535}, // Right

      // Interior walls (these are only visible within the flashlight radius)
      {x: 75,  y: 25,  w: 10,   h: 100},
      {x: 75,  y: 165,  w: 10,   h: 220},
      {x: 75,  y: 425,  w: 10,   h: 90},
      {x: 145,  y: 25,  w: 10,   h: 100},
      {x: 195,  y: 25,  w: 10,   h: 100},
      {x: 195,  y: 115,  w: 75,  h: 10},
      {x: 75,  y: 115,  w: 75,  h: 10},
      {x: 75,  y: 165,  w: 200,  h: 10},
      {x: 265,  y:115,  w: 10,   h: 55},
      {x: 75,  y: 375,  w: 165,  h: 10},
      {x: 75,  y: 425,  w: 215,  h: 10},
      {x: 280,  y: 295,  w: 10,   h: 140},
      {x: 235,  y: 355,  w: 10,   h: 30},
      {x: 105,  y: 345,  w: 140,  h: 10},
      {x: 155,  y: 295,  w: 135,  h: 10},
      {x: 155,  y: 255,  w: 10,   h: 50},
      {x: 105,  y: 205,  w: 10,   h: 150},
      {x: 75,  y: 515,  w: 210,  h: 10},
      {x: 280,  y: 515,  w: 10,  h: 60},
      {x: 105,  y: 490,  w: 205,  h: 10},
      {x: 105,  y: 450,  w: 205,  h: 10},
      {x: 105,  y: 450,  w: 10,  h: 50},
      {x: 155,  y: 255,  w: 155,   h: 10},
      {x: 115,  y: 205,  w: 195,   h: 10},
      {x: 300,  y:95,  w: 10,   h: 115},
      {x: 235,  y: 85,  w: 75,  h: 10},
      {x: 300,  y:255,  w: 10,   h: 205},
      {x: 300,  y:490,  w: 10,   h: 85},
      {x: 225,  y: 25,  w: 10,   h: 70},
      {x: 345,  y: 25,  w: 10,   h: 320},
      {x: 345,  y: 345,  w: 225,   h: 10},
      {x: 345,  y: 395,  w: 60,   h: 10},
      {x: 465,  y: 395,  w: 60,   h: 10},
      {x: 345,  y: 395,  w: 10,   h: 180},
      {x: 515,  y: 395,  w: 10,   h: 180},
      {x: 565,  y: 345,  w: 10,   h: 180},
      {x: 565,  y: 525,  w: 50,   h: 10},
      {x: 605,  y: 300,  w: 10,   h: 230},
      {x: 655,  y: 165,  w: 10,   h: 410},
      {x: 405,  y: 300,  w: 205,   h: 10},
      {x: 405,  y: 255,  w: 205,   h: 10},
      {x: 405,  y: 225,  w: 205,   h: 10},
      {x: 605,  y: 225,  w: 10,   h: 40},
      {x: 405,  y: 255,  w: 10,   h: 50},
      {x: 405,  y: 25,  w: 10,   h: 210},
      {x: 465,  y: 165,  w: 195,   h: 10},
      {x: 465,  y: 85,  w: 10,   h: 90},
      {x: 465,  y: 85,  w: 225,   h: 10},
      {x: 685,  y: 85,  w: 10,   h: 25},
      {x: 685,  y: 150,  w: 10,   h: 425},
      {x: 745,  y: 20,  w: 10,   h: 345},
      {x: 745,  y: 410,  w: 10,   h: 120},
      {x: 745,  y: 525,  w: 70,   h: 10},
      {x: 805,  y: 450,  w: 10,   h: 85},
      {x: 865,  y: 450,  w: 10,   h: 85},
      {x: 805,  y: 445,  w: 70,   h: 10},
      {x: 865,  y: 525,  w: 140,   h: 10},
      {x: 745,  y: 410,  w: 145,   h: 10},
      {x: 935,  y: 410,  w: 40,   h: 10},
      {x: 745,  y: 355,  w: 170,   h: 10},
      {x: 905,  y: 90,  w: 10,   h: 275},
      {x: 845,  y: 90,  w: 60,   h: 10},
      {x: 845,  y: 90,  w: 10,   h: 245},
      {x: 785,  y: 20,  w: 10,   h: 315},
      {x: 785,  y: 325,  w: 60,   h: 10},
    ];
  }

  display() {
    for (let i = 0; i < 4; i++) {
      let wall = this.walls[i];
      image(stoneWall, wall.x, wall.y, wall.w, wall.h);
    }

//creating the masking
    for (let i = 4; i < this.walls.length; i++) {
      let wall = this.walls[i];
      // Create a mask for the wall
      drawingContext.save();
      drawingContext.beginPath();
      drawingContext.arc(player.x, player.y, lightRadius, 0, TWO_PI);
      drawingContext.clip();
      image(stoneWall, wall.x, wall.y, wall.w, wall.h);

      drawingContext.restore();
    }
  }

The outline of the maze itself can be seen in this image below which I took before I made the maze pitch black apart from the flashlight.

The flashlight itself is another thing I am very proud of as I wanted to make it look as natural as the way the light coming from a flashlight looks like. This means it has a bright center and a smooth gradient to transparent. For this effect, I had to learn how to use the blendMode in p5js which allowed me to create it in the easiest way. The code for this can be seen below.

function drawFlashlight() {
  fill(0);
  noStroke();
  rect(0, 0, width, height);

  blendMode(SCREEN); 
  drawingContext.globalCompositeOperation = 'lighter'; 

  // Draw the flashlight gradient
  let gradient = drawingContext.createRadialGradient(
    player.x, player.y, lightRadius / 4,
    player.x, player.y, lightRadius 
  );
  gradient.addColorStop(0, 'rgba(255, 255, 255, 1)');
  gradient.addColorStop(1, 'rgba(0, 0, 0, 0)'); 
  drawingContext.fillStyle = gradient;
  drawingContext.beginPath();
  drawingContext.arc(player.x, player.y, lightRadius, 0, TWO_PI);
  drawingContext.fill();
  blendMode(BLEND);
}

The result of this and the masking can be seen in the image below (with a peep of one the traps – the mummy):

The game proved to be more challenging than I anticipated, and I quickly realized I had set the bar a little to high for myself. Originally, I wanted the player to be a sprite of an archeologist and to have all the booby traps be animated and moving. However, with time constraints and animation struggles, I wasn’t able to do that (but would love to try and incorporate in the future). I also wanted for the cat to somehow appear at the edge of the flashlight’s radius when the ‘C’ key was pressed, the radius of the flashlight expanded, and the meow sound occurred.

Overall, I am still very proud of the game I ended up creating. It is fun, has an overarching Egyptian theme through carefully selected images and even the Papyrus font, and has a niche to it that sets it apart from other games. I learned a lot about p5js and how to code new things while working on this game, and I hope you enjoy playing it!

Concept

Link to Sketch: https://editor.p5js.org/sa8831/sketches/R-3aQof8X

Inspired by a small app I made during high school (Refer to the blog about Midterm progress),  I decided that for the upcoming midterm project, to create an interactive visual novel game. The game takes place in a school of “The Periodic Table” where chemical elements are personified as classmates and teachers. Throughout the game, the user plays as a personified version of Carbon meets other elements like Hydrogen and oxygen to discuss who they are. However, there are 2 endings to this game, where after interacting with either characters, each gets a different ending and a different activity.

How the game works:

How the Periodic Table Academy Game Works (Updated Version):

• Starting the Game:
  • When the game starts, a title screen with a Play button appears. Upon clicking the Play button, the game transitions to the instruction screen.
  • Instructions are displayed, welcoming the player to the Periodic Table Academy and explaining that the player can click the Play button again to begin the game. The player is presented with two characters to interact with: Oxygen and Hydrogen. The characters are displayed on the screen, and the player can choose who to talk to by selecting an option like “Talk to Oxygen” or “Talk to Hydrogen”.

• • If the player chooses to talk to Oxygen, they enter the oxygen-talk state. Oxygen responds with different dialogue options like:
    • How are you?
    • Tell me about yourself
    • Bye
  • Based on the selected option, the game displays different responses from Oxygen, with the dialogue box updating each time.
  • If the player selects “Bye”, the game moves into a cutscene where Oxygen says goodbye, and then the game transitions to one of the endings after a short delay (CO2).Hydrogen’s Dialogue:
    • Similarly, if the player chooses to talk to Hydrogen, they enter the hydrogen-talk state. Hydrogen responds with dialogue options such as:
      • How are you?
      • Tell me about yourself
      • Bye
    • The game progresses similarly as with Oxygen, with the player receiving different responses from Hydrogen.
    • Selecting “Bye” leads to a cutscene where Hydrogen says goodbye, followed by a transition to another ending (C-H).

 

Endings:

• • • • There are two possible endings:
        • CO2 (Carbon Dioxide): If the player interacts with Oxygen, they receive the CO2 ending. The game then displays a message congratulating the player for making CO2.
        • C-H (Hydrocarbon): If the player interacts with Hydrogen, they receive the Hydrocarbon ending. The game congratulates the player for making Hydrocarbons.Interactive Ending:
          • During the ending state, the player can click around the screen to generate particles that represent either CO2 or Hydrocarbons depending on the ending.
          • Particles are displayed on the screen, and each particle shows a label (either “CO2” or “C-H”) as it moves upward. These particles are generated when the player clicks anywhere on the screen.

Game Design

I initially wanted to draw a personified Carbon and allow the user to move using keys A and D to include a walking animation, to go either direction to the characters. However, due to breaking the screen and difficulty to link my spritesheet with the character, I removed that idea but instead made it inspired by the game Undertale:

(inspiration for the dialogue)

In addition to this, the endings involves particles that resembles a “bond” between 2 characters. I aim for the particles to represent the compounds for reacting Carbon with either Oxygen or Hydrogen to create molecules (like C-H or Hydrocarbons, and Carbon Dioxide or CO2).

 

Highlights/ Challenges:
The highlights of this would be this snippet:

// Particle Class
class Particle {
  constructor(x, y, text) {
    this.x = x;
    this.y = y;
    this.size = random(20, 50);
    this.text = text;
    this.ySpeed = random(-2, -1);
  }

  move() {
    this.y += this.ySpeed; // Move upward
  }

  display() {
    fill('#ADD8E6');
    noStroke();
    ellipse(this.x, this.y, this.size);
    fill(255);
    textSize(this.size / 2);
    text(this.text, this.x, this.y);
  }
}

// Generate particles on click
function mousePressed() {
  if (state === 'ending') {
    let newParticle = new Particle(mouseX, mouseY, endingType);
    particles.push(newParticle);
  }
}

Because of clicking around the ending screen to get the needed “molecule” for each ending.

However, the challenges involves the following:

1. Ensuring smooth user interaction with the character dialogues was challenging, especially with different choices for interactions such as “How are you?”, “Tell me about yourself?”, and “Bye.”
   • I structured the dialogue system using buttons that allow for straightforward user input. This kept the interactions clean, with each character giving distinct options based on the user’s previous choices. This helped in providing a more guided yet flexible experience.
2. Since I wanted to integrate Object-Oriented Programming, handling multiple characters (Oxygen and Hydrogen) with unique behaviors, interactions, and background transitions was tricky, especially with the game requiring seamless transitions from one scene to another.
   • I utilized OOP principles to create classes for characters, backgrounds, and game states. This allowed for easy management of multiple elements interacting with each other, while ensuring that transitions and character interactions felt fluid and natural. The background changed dynamically as Carbon moved, which helped convey the progression of the game.
3. Another challenge was implementing multiple endings depending on which character the player interacts with first and ensuring the game could be easily restarted without refreshing the page.
   • I included an instruction screen and a restart button after each ending. To handle game state management, I kept track of the character interactions and ensured the game’s ending sequences could be triggered based on the order of choices. The restart button was designed to reset the game state while keeping the experience accessible without needing to reload the page.
4. The game’s concept of displaying chemistry information such as oxygen bonding with carbon, and visual representations of molecules like CO2 and hydrocarbons, needed to be both educational and engaging.
   • I decided to keep the visual representations simple, using floating shapes and rain animations to visually communicate the chemical reactions. This allowed players to understand the results of their choices (CO2 and hydrocarbons) in a non-overwhelming way.

Improvements

• Enhancing Character Interactions:

  • Add more diverse dialogue options that react to previous choices, making conversations more personalized and dynamic.

• Expanding the Periodic Table Academy Environment:

  • Introduce additional elements from the periodic table with unique interactions, personalities, and visual effects.
  • Create puzzles or mini-games based on chemical properties to increase educational value.

• Improved Visual Effects for Chemical Reactions:

  • Implement particle effects, such as glowing or color-changing molecules when bonding occurs, to enhance visual appeal and illustrate chemical reactions more vividly.

Final Update: Concept

At first, I wanted my project to recreate my old, cluttered workspace in Bangladesh—full of life, creativity, and memories. But after moving into my dorm, I realized my space now is the opposite: empty, open, and full of possibility.

So instead of a busy, object-filled world, my interactive artwork in p5.js reflects this new beginning. The emptiness isn’t just emptiness—it’s potential. It invites exploration, just like my dorm did when I first moved in. This project became more than just a recreation; it’s a reflection of change, growth, and the spaces we make our own.

️ How It Works

This p5.js sketch opens with a sliding door animation triggered by a double-click—inviting the user into my new, reimagined space. The background is made of looping breathing frames (3 total), giving life to an otherwise still room. All visuals are hand-drawn—hair, furniture, plants, and even a little desktop cat.

Hair animations are split into base, fringe, and left/right segments. Each segment has its own independent frame logic, animated dynamically in code, not as spritesheets—saving memory while giving me more layering control. The breathing and hair create ambient movement that never overwhelms the canvas.

There’s interaction too:

• Hovering over the lamp activates its glow and animates its arm.

• Clicking the mirror brings up a live webcam feed. You can “capture yourself” inside the mirror.

• Clicking the cat opens a surprise sketch.

• Clicking the Spotify icon links to my actual profile—and starts background music.

I also display a live UAE time clock on the desk monitor, updating every second. Because yes, I coded that too.

 What I’m Proud Of

• The balance between aesthetics and interaction. I didn’t just cram in clickable objects—I made them meaningful, subtle, and thematic.

• Hair movement logic. Animating hair in separate segments and syncing their speed gave it a much more natural feel than I could’ve achieved with pre-rendered spritesheets.

• // Left hair animation
  image(leftHairFrames[currentLeft], xPos - xOffset, yPos - yOffset, hairWidth, hairHeight);
  leftBlend += hairSpeed;
  if (leftBlend >= 1) {
    leftBlend = 0;
    currentLeft = nextLeft;
    nextLeft = (nextLeft + 1) % leftHairFrames.length;
  }
  

   

• Mirror interaction. Using cam.get() and masking the feed to fit into an oval gave the illusion of a real, personal reflection without needing AR libraries.

• Sound integration. Audio feedback (the knock, the music) grounds the scene and enhances immersion without stealing the spotlight.

Challenges & Improvements

1. Asset Load Limits & Compression Woes
Initially, I tried creating one big spritesheet for all hair frames—until p5.js (rightfully) panicked. Compressing the sheet butchered the image quality, so I scrapped it in favor of individually loaded and layered PNGs.

// Breathing animation logic
image(breathingFrames[currentFrame], 0, 0, width, height);
tint(255, 255 * blendAmount);
image(breathingFrames[nextFrame], 0, 0, width, height);
blendAmount += fadeSpeed;

if (blendAmount >= 1) {
  blendAmount = 0;
  currentFrame = nextFrame;
  nextFrame = (nextFrame + 1) % breathingFrames.length;
}
noTint();

 

2. Interactivity Clutter
I wanted everything to be interactive. Bad idea. Midway through, I remembered something Professor Mang said: it’s better to be clean and compelling than overloaded. So I scaled back. Some items are just pretty. And that’s fine.

3. Mirror Lag on Some Browsers
Depending on user permissions, the webcam sometimes doesn’t load right. I didn’t implement a fallback system, but it’s something I’d add next time.

 Conclusion

This project started as an homage to an old space but became a meditation on new beginnings. It’s my first time making an ambient interactive piece—part game, part diary, part room. It’s not perfect, but it’s mine. And like any good workspace, it’s full of potential.

For my midterm project, I decided to do a Space Invaders-inspired shooting game with space ships and aliens. The game was partly inspired by a mobile game called: Radiant. The game’s main feature was an array of weapons in which the player could freely switch between. Because each weapon type had its own advantages and disadvantages, you had to switch between all of them to successfully complete the game. I wanted to incorporate this element into my shooter game to make it more unique and be more interactive and replayable.

Game Design

The game begins on a menu screen, where the player sees the game title and has access to all the instructions they need to play the game. I found a really cool arcade-style font that really matched the theme of the game. Because the game instructions were relatively minimal there was no need to have mutliples screens of text.

Then when the game begins the player is spawned and enemies start spawning from the top of the screen at regular intervals, with the interval decreasing over time to increase the difficulty of the game. The enemies path directly towards the player, ending the game if even one of them touches the player. Because of the number of enemies already present, I did not make the enemies fire any shots.

The player had access to 6 different type of weapons, normal shots, machine gun, shot gun, laser and other settings that all had their own characteristic. The player could switch at anytime by pressing the number keys 1-6. Each type of shot deals different amounts of damage to enemies.

When the player is hit by an enemy the game cuts to a GAME OVER screen. The player can then press play again to restart the game.

Challenges

One problem I continuously faced was when the alien sprites because of the way they were coded, were often the wrong size and unable to be resized by the variables. I had to consult  p5 reference for a while to fix this.

Another problem I had faced for a long time was getting the shot type to switch to the proper type of shots. After tutorials and looking at other projects I switching with cases allowed me to control this as well as shot spread with the keyboard numbers.

Lastly, one thing I was surprised was so challenging was assigning a sound to play when the game ended (I ended up forgoing this). There was no way to easily play a sound once without looping when my game state switched.

  damage = 6
  break
case 4:
  color = [255, 255, 0]
  width = 15
  height = 10
  speed = 12
  damage = 1.5
  break;
case 5:
  color = [255, 50, 255]
  width = 8
  height = 24
  speed = 15
  damage = 3
  break;
case 6: 
  color = [170, 50, 255]
  width = 5
  height = 35
  speed = 25
  damage = 3
  break
}

 

function keyPressed() {
  if (key === '2') {
    shotType = 2
    cooldown = 150
  } else if (key === '1') {
    shotType = 1
    cooldown = 400
  } else if (key === '3') {
    shotType = 3
    cooldown = 800
  } else if (key === '4') {
    shotType = 4
    cooldown = 600
  } else if (key === '5') {
    shotType = 5
    cooldown = 500
  } else if (key === '6') {
    shotType = 6
    cooldown = 600;
  }
}

 

Future Improvements

There are so many ways to potentially improve this game. One way is to definitely have more enemy types that would resist or be weak towards different types of projectiles. This would further incentivise the player to switch weapons, allowing the game to be more engaging.

Another potential improvement is improving the movement patterns of the aliens to be more challenging. If they moved unpredictably towards the player that allowed them to “dodge” shots, the game would have a whole other level of challenge.

Lastly, A scorekeeping method or score in the top left corner would be very useful and would make the game feel like its progressing- this is probably the first change I would want to implement.

Concept

I’ve always been fascinated by spooky stories, yet wanted to create something more lighthearted than a typical horror game. That is how I ended up making a short, click-based project in which the player buys a haunted house at a bargain price and must purge it of unwanted guests—literally ghosts—to unlock its true potential. From the outset, I imagined a game with a touch of urgency: each wave of ghosts adds just enough pressure to keep your heart rate up, but not so much as to be punishing or relentlessly scary. The result is a game that blends frantic clicking with a fun, eerie atmosphere and a simple storyline that sets the stakes clearly: fail, and the ghosts overwhelm you; succeed, and the house is yours, free of all things that go bump in the night.

To cement that narrative, I designed three distinct levels, each with its own flavor of tension. Level 1’s stationary ghosts ease the player in, Level 2’s moving ghosts ramp up speed and require more hits, and Level 3 features a boss ghost who teleports unpredictably to keep the player on their toes. Across these levels, the fundamental goal never changes—click fast, or you risk running out of time—but the variety of ghost behavior and the gradually intensifying difficulty create a neat progression. The final reward is a bright, newly revealed house, signifying the end of the haunting and the triumph of actually getting to live in your newly bought property.

How the Project Works

The code behind this game employs a simple state machine to orchestrate its various parts. I found this approach more intuitive than cramming all logic into one giant loop. Whenever the player transitions from, say, the INTRO state to LEVEL1, the script calls startLevel(level), which resets the timer, spawns the appropriate ghosts, and ensures there’s no carry-over from earlier states. Here is a small excerpt that illustrates how the game transitions from one level to the next or ends if all ghosts are defeated:

if (ghosts.length === 0) {
  if (level === 1) {
    state = "LEVEL2";
    startLevel(2);
  } else if (level === 2) {
    state = "LEVEL3";
    startLevel(3);
  } else if (level === 3) {
    state = "WIN";
    ghostSound.stop();
    victorySound.play();
  }
}

I’m particularly proud of how coherent each ghost type’s logic is, thanks to object-oriented design. I broke down the ghosts into three classes—StaticGhost, MovingGhost, and BossGhost—so each can handle its own movement and hit requirements. For instance, the MovingGhost class includes velocities in both x and y directions. It updates its position each frame and bounces off the canvas edges, which felt more elegant than scattering if-conditions all over the main draw() loop. This design choice also eases extension: if I someday add a new ghost that splits into two smaller ghosts on hit, I can isolate that behavior in yet another class.

Moreover, I love the inclusion of sound elements, as it heightens the atmosphere. The ghostly background audio starts the moment you tackle Level 1, giving a sense of stepping into a haunted property. On every successful hit, a short “blast” sound triggers, reinforcing the feedback loop for players clicking in a hurry. When the boss ghost is defeated, the game transitions to a “WIN” screen with a triumphant sound, showing off the newly purified house. These little touches bring a pleasant cohesiveness to the otherwise basic act of clicking on sprites and add a layer of fun that purely visual feedback might not achieve.

Areas for Improvement & Challenges Faced

While I’m delighted with the final result, I definitely noticed some spots that could be enhanced through further iteration. First, game balancing was tricky. If I set the time limits too high, the game lost its tension because players could leisurely pick off ghosts. If I made them too strict, new players often found themselves losing before they fully grasped the ghost patterns. I settled on modest values for each level, but it still demands some quick reflexes—if someone isn’t used to rapid clicking, they might find the default times a bit harsh. Introducing difficulty modes, or maybe timed boosts that freeze the ghosts for a short period, would give me more fine control over that difficulty curve and cater to different skill levels.

Another challenge was ensuring that state transitions stayed seamless. At one point, I had ghosts from Level 1 lingering into Level 2, causing the dreaded “two waves at once” bug. The fix involved carefully resetting arrays and timers inside startLevel(level) and confirming no leftover references were carried over. Though it took some debugging, it taught me the importance of thorough housekeeping when cycling through game phases—particularly in an experience that uses back-to-back waves, each with its own unique ghost behaviors. If I expand the project in the future, perhaps adding more levels or extra ghost abilities, I’ll rely heavily on these same organizational principles to keep the code from becoming unwieldy and prone to surprises. I feel the game meets my initial ambition: to craft a short, fun, and spooky challenge that doesn’t overstay its welcome. It balances straightforward gameplay—just point-and-click to vanquish ghosts—with enough variety to keep the three levels distinct and interesting. As I continue refining or building upon the concept, I plan to experiment with new ghost types or reward systems that push the idea even further, but I’m proud of how the current version stands on its own as a playful haunted-house journey.

Concept:
My midterm project was inspired by classic arcade games like Space Invaders and Galaga. I wanted to create my own shoot ‘em up game set in space, and try to capture that retro feel while throwing some new elements into the mix.
I made the choice to have the player character and their bullets be pixelated, while the enemies have a more modern look and shoot laser beams in order to create some distinct contrast. I also introduced additional obstacles in the form of slow-moving asteroids and diagonally-moving comets, both of which share in the more modern appearance. I only included sound effects relevant to the player character, so they lean towards the older side.

How it Works:
As for the actual gameplay, I decided to confine the player to a single static screen, where obstacles (including enemies) will continually descend from the top. Since I didn’t design multiple levels or an upward scrolling mechanic, I chose to increase the spawn rate of obstacles as the round goes on to increase the difficulty. The player will continue until their health runs out, at which point they are prompted to save their score.
The player earns points by shooting and destroying an obstacle, but they will also earn a smaller amount for simply allowing the obstacle to pass them and be cleared off-screen. If the player collides with the obstacle, they will instead lose points and destroy the obstacle.

Highlights:
Using OOP to manage different obstacle sub-types + Detecting and handling collisions during gameplay:

class Obstacle {
  constructor(x, y) {
    this.x = x;
    this.y = y;
    this.radius = 32;
    this.health = 3;
  }
  display() {
    this.update();
    circle(this.x,this.y,this.radius*2);
  }
  update() {
    if (gameRunning()) {
      this.y += 0.5;
    }
  }
  check() {
    if (this.health <= 0) {return}
    // // Flag obstacles below screen to be cleared
    if (!onScreen(this)) {
      // console.log("Destroy offscreen");
      this.health = 0;
      game.score += 5;
    }
    // // Check collision w/ player
    if (checkCollision(this, game.player)) {
      this.health = 0;
      if (!game.player.shielded) {
        game.score -= 10;
        game.player.health -= 1;
        playHurt();
        if (game.player.health <= 0) {return}
        game.player.iframes = 60;
        game.player.shielded = true;
      }
    }
    // // Check collision w/ player bullets
    for (let i = 0; i < game.player.bullets.length; i++) {
      if (checkCollision(this, game.player.bullets[i])) {
        if (!game.player.bullets[i].spent) {
          game.player.bullets[i].spent = true;
          this.health -= 1;
          if (this.health <= 0) {
            game.score += 20;
          }
        }
      }
    }
  }
}
class Enemy extends Obstacle{
  constructor(x, y) {
    // // Gameplay attributes
    super(x, y);
    this.radius = 32;
    this.sprite = enemySprite;
    this.firerate = 0.3;
    this.offset = random(1000);
  }
  display() {
    this.update();
    image(this.sprite, this.x, this.y, 64, 60);
    if (debug) {circle(this.x, this.y, this.radius*2)}
  }
  update() {
    if (gameRunning() && onScreen(this)) {
      this.x += sin((frameCount + this.offset) * 0.05) * 2;
      this.y += 0.5;
      if (triggerFire(this.firerate)) {
        append(game.enemyBullets, new Bullet(
          this.x, this.y+this.radius));
      }
    }
  }
}

Using helper functions instead of cramming everything in-line:

// // Determine whether to shoot on current frame
function triggerFire(rate) {
  let trigger = Math.floor(60 / rate);
  return frameCount %  trigger === 0;
}
// // Check collision of two objects (circle bounding)
function checkCollision(one, two) {
  if (dist(one.x, one.y, two.x, two.y) <= 
      (one.radius + two.radius)) {return true}
  return false;
}
// // Spawn a new enemy/asteroid/comet
function spawnObstacle(type) {
  let newX = Math.floor(random(30, width - 30));
  let newY = Math.floor(random(-50, -200));
  let obs;
  switch(type) {
    case 0:
      obs = new Enemy(newX, newY);
      append(game.enemies, obs);
      break;
    case 1:
      obs = new Asteroid(newX, newY);
      append(game.asteroids, obs);
      break;
    case 2:
      newX = newX % 30;
      obs = new Comet(newX, newY);
      append(game.comets, obs);
      break;
    default:
      console.log("Spawn " + type);
  }
  append(game.obstacles[type], obs);
  if (debug) {console.log("Spawn new " + type)}
}
// // Standardize button styling for menu
function doStyle(elem) {
  // // Styling
  elem.style("font-size", "16px");
  elem.style("font-family", "sans-serif");
  elem.style("background-color", "rgb(20,20,20)");
  elem.style("color", "whitesmoke");
  elem.style("cursor", "pointer");
  // // Hover behaviour
  elem.mouseOver(() => {
    elem.style("background-color", "firebrick");
  });
  elem.mouseOut(() => {
    elem.style("background-color", "rgb(20, 20, 20)");
  });
}
// // Handle gameover
function triggerGameover() {
  gameState = 'gameover';
  game_bgm.stop();
  // player_shoot.stop();
  // player_hurt.stop();
  if (game) {
    game.gameover = true;
    // // Play win sound for score (temp)
    if (game.score > 500) {
      win_sound.play();
      return;
    }
  }
  lose_sound.play();
}

Areas for Improvement:
Since I spent most of my time on the gameplay itself, I feel like I lost out on the visual appeal in several places. For example, my menu screen has some styling on the buttons, but the font is fairly standard instead of using a pixelated font to add to the retro aesthetic. I also had started to work on a leaderboard system, but I belatedly realized that it would download a CSV file to the computer instead of saving the results to the relevant asset file.
Another area for improvement is the gameplay itself. I began to add power ups that would spawn in the playable area, but didn’t have time to fully implement them. The sound design was also a last minute addition that I completely forgot about until I started writing the blog post. Finally, the difficulty ramp-up could use some adjustment. Each obstacle type has semi-randomized parameters within differing bounds, but it still feels like something is a bit off about it.

(Fullscreen)