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.