Concept

Hogwarts Experience is an interactive web experience inspired by the whimsical world of Hogwarts.
It blends a classic sorting quiz, a maze challenge, and wand selection into one compact game built entirely in JavaScript (using p5.js).

The idea was to explore how storytelling, visuals, and interactivity could merge to create something that feels alive; something more than just a quiz or a mini-game.

Inspiration

From my fascination of JK Rowling’s use of symbols (a hat, a house, wand) in Harry Potter explores identity and choice. I wanted to capture that feeling of “who am I?” in a lightweight browser experience.

Technically, this project was also a personal experiment:
how far can I go with only vanilla p5.js, with minimal frameworks and assets, what be drawn or generated?

Visual Elements

The visuals are all hand-coded with p5.js shapes and color palettes chosen to reflect the four houses:

• Gryffindor: warm reds and golds, courage in motion
• Ravenclaw: deep blues and calm precision
• Hufflepuff: mellow yellows and earthy tones
• Slytherin: sleek greens and silvers, a hint of ambition

[I got the color codes from codepen.io]

The wand selection features small glowing particle bursts when you find your correct match, a simplified particle system I built directly into the Wand class.
It’s minimal but expressive: circles of light that rise and fade like sparks from Ollivander’s wand shop.

Interaction & Controls

• The quiz is fully clickable — each answer dynamically updates your house “weight.”
• Once sorted, you navigate a small maze using arrow keys (or WASD).
• You can activate your house ability with a single keypress (spacebar).
• The wand test responds to clicks, showing visual feedback for correct or incorrect matches.

Each stage was designed to feel self-contained but connected, a simple rhythm of choice, discovery, and action.

Sound Design

Sound is subtle but intentional.
A soft background theme plays during the game, punctuated by short cues:

• a shimmer when your wand responds,
• a gentle whoosh for movement,
• a celebratory chime when you win,
• and scary dementor sound when you fail to exit the maze.

All sound events are managed with a simple sound registry that starts, stops, and restarts based on player state. I tried to get rid of any overlaps or chaos. I wanted it to add atmosphere without overwhelming the visuals.

Code Architecture

The game is built around a few modular classes:

• Question → handles quiz text, answers, and house mapping
• Player → manages movement, collision, and ability us
• Enemy → manages the enemies in the maze
• Wand → merges wand logic and particle effects for magical feedback
• GameManager (lightweight) → controls flow between quiz, wand test, and maze

Each class does one job well.
The code favors clarity over complexity; the division into classes make it readable, flexible, and easily expandable.

Code Snippet to Highlight

test() {
    if (this.isCorrect) {
        this.glowing = true;
        for (let i = 0; i < 20; i++) {
            this.particles.push({
                x: this.x,
                y: this.y,
                vx: random(-3, 3),
                vy: random(-5, -1),
                life: 60,
                success: true
            });
        }
        return true;
    } else {
        for (let i = 0; i < 10; i++) {
            this.particles.push({
                x: this.x,
                y: this.y,
                vx: random(-3, 3),
                vy: random(-5, -1),
                life: 60,
                success: false
            });
        }
        return false;
    }
}

It’s small, but it brings the world to life, literally adding a sparkle of magic when you choose correctly.

Future Additions

• Better sprites & art direction: hand-drawn assets for characters, wands, and the maze walls
• Fullscreen adaptive display: scaling visuals gracefully across devices
• House competition system: each player’s score stored via browser cookies or localStorage, allowing a shared “House Points” leaderboard
• Integration with ml5.js: experimenting with emotion or gesture recognition to let your facial expression or hand movement influence sorting outcomes

Each of these is a small step toward a more responsive, immersive experience,  a bit closer to real enchantment.

Concept

For my midterm project, I’m building an interactive Hogwarts experience. The player starts by answering sorting questions that place them into one of the four houses. Then they get to choose a wand and receive visual feedback to see which wand truly belongs to them. After that, the player will enter their house’s common room and either explore various components in the room or play a minigame to earn points for their house.

The main idea is to capture the spirit and philosophy of each Hogwarts house and reflect it in the minigames, so the experience feels meaningful and immersive. Instead of just random games, each minigame will be inspired by the core traits of Gryffindor, Hufflepuff, Ravenclaw, or Slytherin.

Design

I want the project to feel smooth and interactive, with a focus on simple controls mostly through mouse clicks. Each stage (from sorting, to wand choosing, to the common room minigames) will have clear visual cues and feedback so the player always knows what to do next.

For the minigames, I’m aiming for gameplay that’s easy to pick up but still fun, and thematically tied to the house’s values. The design will mostly use basic shapes and animations in p5.js to keep things manageable and visually clean.

Challenging Aspect

The part I’m still figuring out and find the most challenging is designing minigames that really match each house’s philosophy but are also simple enough for me to implement within the project timeline. It’s tricky to balance meaningful gameplay with code complexity, especially because I already have a lot of different systems working together.

Risk Prevention

To manage this risk, I’ve been brainstorming minigames that are easy to build, like simple clicking games for Gryffindor’s bravery or Memory games for Ravenclaw, while still feeling connected to the houses’ themes. I’m focusing on minimal input and straightforward visuals so I can finish them reliably without overwhelming the code.

What I enjoyed most in this piece is how it drags computer vision down from the pedestal of labs and military contracts into something artists and students can actually play with. The examples, from Krueger’s Videoplace to Levin’s own Messa di Voce, remind me that vision doesn’t have to mean surveillance or soulless AI pipelines. It can also mean goofy games, poetic visuals, or even awkward belt installations that literally stare back at you. I like this take, it makes technology feel less like a monolith and more like clay you can mold.

That said, I found the constant optimism about “anyone can code this with simple techniques” a little misleading. Sure, frame differencing and thresholding sound easy enough, but anyone who’s actually tried live video input knows it’s messy. Lighting ruins everything, lag creeps in, and suddenly the elegant vision algorithm thinks a chair is a person. The text does mention physical optimization tricks (infrared, backlighting, costumes), but it still downplays just how finicky the practice is. In other words, the dream of democratizing vision is exciting, but the reality is still a lot of duct tape and swearing at webcams.

What I take away is the sense that computer vision isn’t really about teaching machines to “see.” It’s about choosing what we want them to notice and what we conveniently ignore. A suicide detection box on the Golden Gate Bridge makes one statement; a silly limbo game makes another. Both rely on the same basic tools, but the meaning comes from what artists decide to track and why. For me, that’s the critical point: computer vision is less about pixels and algorithms and more about the values baked into what we make visible.

Concept

For this exercise, I wanted to merge two things: playful interactivity and meaningful (well almost) outcome. I came up with this Tetris-like game where instead of geometric blocks, words fall from the sky. Players can move these word blocks left or right with arrow keys to stack them into bizarre sentences or whatever they like.

The sentences hardly make sense; in fact, the randomness of the generated words is something that makes the results funny. This can be perceived as a silly project but it’s fun. Stack words – make nonsense – laugh.

Inspiration

The inspiration came from two souces:

1. Tetris game
2. Text Rain (by Camille Utterback, where letters fall and interact with the human body)

I wanted to combine the two ideas intro something playful but also generative, where the player becomes either a poet or a chaotic builder (or both) depending on the words that randomly fall and where they place them.

Code Structure

Here is the list of things I implemented this with:

• Array of words (tried to include nouns, verbs, adjectives, adverbs, connectors; however, this can be modified for the code meaning user can use any array of any words they like)
• fallingWord object that moves down the grid
• blocks array to store all placed word, and collision detection so blocks stack on top of each other or store at the floor.
• Keyboard controls to move words left and right within the canvas
• A small function to resize text dynamically. This was done keeping in mind that is user wants longer words in the array and they will be able to do so as the font size will be adjusted as needed.

Every new word is randomly chosen from the array, dropped from the top, and the loop continues.

Reflection

I liked how this project was fairly simple yet becomes engaging once the player is allowed to have some control. This is a result of both randomness (of the word array) and control (the stacking mechanism).

Challenges:

• Making sure words didn’t move out of canvas. I tried to put this condition in the same one as if keyPressed but that wasn’t to work. It turned out I have to create a nested condition to implement this.
• Handling long words that wouldn’t fit in the blocks. I thought whether to allocate more than 1 blocks for long words, but i realized that adjusting the font size is much convenient.

Future Improvements

• Add scoring system: If a player completes a sentence, they get a point. This requires the rules of grammar and is too difficult for me at present.
• Make the termination case: for now, I didn’t instruct the code what to do when the canvas is full. I think this is necessary for a game, but mine isn’t yet.

Reading Norman’s The Psychology of Everyday Things made me notice how often bad designs are excused focusing on the supposed incompetence of the users. For instance, his discussion of Norman Doors was something I could absolutely relate because on multiple occasions, I personally have pushed the wrong side of a glass door only to feel clumsy and inobservant even though, as he points out, the real failure is in the design and not the user (me). That shift, blaming the design instead of the user, was oddly liberating. It reminded me that designs should communicate clearly and if I can’t figure out, the system image is broken. I started thinking about my own sketches for the weekly productions in p5: sometimes when I code and interaction, I get worried that people may not use it ‘the right way.’ But Norman’s text made me realize that I am responsible for building the right signifiers, the visual or behavioral cues that make the action discoverable.

Another part that stuck with me was Norman’s point that designers often create for how they wish people behave, and not how they realistically behave. This discrepancy, I realized, is the reason behind a lot of products failing to flourish as much as they were projected to. I found myself guilty of the same, to be frank; I oftentimes assume people will read the readme.md file or be patient enough to try different keys until something interesting happens. But in reality, users tend much more to attain instant feedback/gratification from an interactive device in this age of technology. It is far beyond ambitious to expect users to get a PhD on my product before they put their hands on that.

Norman’s framework of affordances, signifiers, mapping, and feedback gave me a checklist (literally like a cheat code) that I can use in my projects. I will ask myself upon drafting the project whether it:

• shows what’s possible through the interface
• maps actions to outcomes naturally
• provides a meaningful/satisfying feedback

I want to reimagine some of the (slightly) interactive sketches keeping Norman’s (very reasonable) propositions and later compare them with their counterparts to visualize the narrative I have already subscribed to.

For me, a strongly interactive system is one that goes beyond just reacting. Crawford’s point about how books, movies, or even a refrigerator light don’t really “interact” stuck with me; true interactivity for me now, means both sides listen, think, and respond. It isn’t enough for a system to grab attention or look slick; it has to feel like a conversation. That’s why I think of interactivity less as a switch (on/off) and more as a spectrum. The strongest systems respect the user: they acknowledge input in meaningful ways, they adapt, and they make the user feel like their actions actually matter.

When I think about my own p5 sketches, I realize they often stop at reaction. They respond to a click or a key press but don’t really “listen” deeply. To push them toward stronger interactivity, I could design them to recognize patterns in user input, remember past actions, or even surprise the user with responses that aren’t strictly predictable (sort of something we did for the production in week 2; baby steps but still). For example, instead of a sketch where shapes simply follow the mouse, I could create one where the system builds a visual “memory” of how the user has drawn before and adapts its behavior over time. Though that sounds ambitious, it would turn it from a basic reaction into more of a dialogue.

Ultimately, I think the goal is to make my sketches less like a refrigerator light and more like a partner in conversation. The best interactive systems respect the user’s role, and if my work in p5js can manage to give users that sense of being heard, then I’ll know I’m moving in the right direction.

Concept

I wanted to build something that felt alive but also structured, and the lunar cycle is a great mix of both. The project simulates the eight phases of the moon, from New Moon to Waning Crescent, with randomized textures (spots) and stars to make each redraw unique. The idea is that every click reveals a new “night sky,” giving the viewer a sense of time passing without relying on animation loops.

How It Works

• Moon.js defines a Moon class. Each moon has a position, size, and current phase index. The phase controls how much of the circle is lit and how much is in shadow.

• The surface spots are stored in an array of objects, each with its own position, size, and shade of gray. This randomness makes the moon look organic rather than like a flat white circle.

• I also made sure spots only show up in the “visible” lit portion of the moon, so the shadows aren’t just cosmetic.

• Sketch.js handles the overall scene: the canvas, the star field (also an array of little objects), and the interaction. Every mouse click moves the moon forward by one phase, regenerates its surface spots, and refreshes the stars.

What I’m Proud Of

The hardest and most satisfying part was getting crescents and gibbous phases to look right. p5.js doesn’t have a neat intersection() or shape-clipping tool for arcs, so I had to improvise using combinations of ellipses, arcs. It was like solving a puzzle with the wrong pieces, but in the end it worked.

Another “aha” moment came with the order of drawing. For example, if I drew the stars last, they’d sit awkwardly on top of the moon. If I drew spots before clipping, they’d spill into the shadows. It’s such a small detail, but the sequence of draw calls makes or breaks the illusion.

Aesthetic Choices

• The moon is a soft gray (230) while shadows are much darker, to keep things simple but still distinguishable.

• Stars are randomized each time you click, which makes the scene feel less static.

• The phase name and “day” number are displayed in monospace above the moon to mimic an old-school astronomy chart.

Problems Along the Way

• Figuring out crescents and gibbous shapes took the most trial-and-error. I tried a bunch of naive arc overlaps before landing on my ellipse-mask workaround.

• Getting the spots to fit entirely inside the circle (without spilling over the edge) was trickier than expected; I had to add a distance check plus a little buffer zone.

Casey Reas’ Eyeo 2012 talk, Chance Operations, made me think differently about randomness in art. He shows how even data from something as steadfast as a natural component can generate patterns that are surprising and meaningful when processed through a system with rules. It made me realize that randomness isn’t just chaos, rather it can actually be a tool if some limits are set on this. That idea challenged how I usually approach making things; I used to tend to want complete control, but maybe leaving room for the unexpected could make my work more interesting and dynamic.

For my own work for this weeks production, I’ve tried experimenting with randomness in things like layout, placement, or small visual details so the final piece isn’t predictable. For me, the balance between control and chance is having a framework that guides the work but still allows it to surprise me. I don’t want total randomness, because then it wouldn’t feel like my work at all, but I also don’t want it completely fixed, because then it might feel rigid or boring. I believe we can not overstate the attempt of finding the sweet spot between dictation and improvisation that allows the bounds of structure, and at the same time, manages to surprise with the output.

Concept:

I wanted to make something playful and unpredictable using what we have learned so far: loops, conditionals, and simple shapes. The idea was to fill the canvas with a grid, but instead of every cell looking the same, each square of the grid gets randomly assigned a circle, a square, or a diagonal line. This way, the overall structure feels ordered (in code, not compilation), but the details are different every time you run (or click) the sketch.

Code snippet to highlight:

The piece of code I’m most proud of is the tiny decision that controls the orientation of the lines. Despite it being only an If condition, it has quite an effect on how the final image looks. Without it, all the lines would lean the same way, and the grid would look stiff. With it, each line can either go \ or /, which suddenly makes the whole composition feel more dynamic and unpredictable.

stroke(random(50, 200), random(50, 200), random(50, 200), 220);
strokeWeight(random(1, 4));
let orientation = int(random(2)) // decides orientation of the line
if (orientation == 0) {
  line(i, j, i + space, j + space);
} else {
  line(i + space, j, i, j + space);

 

Reflection and Prospects:

What I like most about this sketch is how structured chaos plays out. The grid keeps everything orderly, but within each cell, there’s randomness that gives the piece character, resulting in the chaotic image we get./
If I were to push it further, I’d try:
– Rotating the rectangles randomly, not just keeping them straight.
– Introducing a shifting color palette that changes slowly over time.
– Adding a gentle animation so the grid breathes instead of sitting still.
For now, though, I think it’s a fun little experiment in how tiny tweaks (like flipping a line) can completely change the energy of a generative artwork.

CONCEPT:
For this assignment, I built a self-portrait entirely out of shapes in p5.js. I wasn’t trying to make something realistic, instead, I went for a cartoon version of myself: a round face, messy hair, glasses, and a simple smile. The idea was to see how much “me” I could get across with just ellipses, arcs, and lines. The output is far from realistic; come on, I am not trying to replace my passport photo with this. The portrait is simple, but I like how it balances between looking generic and still recognizably like me.

HIGHLIGHTED CODE:
The glasses ended up being my favorite part. Without them, the face felt empty, but adding two circles and a line suddenly made it feel right:
  noFill();
  stroke(0);
  strokeWeight(3);
  ellipse(167, 170, 60, 60);
  ellipse(233, 170, 60, 60);
  line(200, 170, 200, 170); // bridge

REFLECTION AND FUTURE WORK:
This was my first attempt at drawing myself, and that too using code; and it showed me how powerful even basic shapes can be. It doesn’t need shading or complex details to read as a face, and luckily identify a person if the components are placed right.

However, if I had more time, I’d like to:
– Make the eyes blink or move with the cursor (saw many do that, i can’t just yet)
– Give the background more personality
– Fix the hair so it looks less like a helmet and more like actual messy hair (pretty doable with multiple ellipses but i reckon there are more efficient ways)
Even with its simplicity, I like how it turned out, it’s definitely not a mirror image, but it’s “me” enough.