Concept

Back in school, they wouldn’t give us the WiFi password, so whenever I opened a browser I got stuck on the “No internet” page with the little dinosaur. With nothing else to do, my classmates and I would end up playing the offline dino game, and it got really competitive as we tried to beat each other’s high scores. That memory is where Desert Runner started. I wanted to keep the same simple, addictive feeling of the dino game but make it my own by bringing my culture into it. Instead of a dinosaur jumping over cacti, the main character is an Emirati man in a kandura, ghutra and agal, and instead of cacti he has to get past animals from the UAE desert.

I also wanted the game to have a goal instead of running forever, so I gave it a story. The character is an NYUAD student who leaves campus on Saadiyat Island and gets lost in the desert. Every road takes him further away, first to Sweihan, then Al Ain, then all the way to Liwa, before he finally finds the long road back to Saadiyat. If you reach 2000 points, an NYU Abu Dhabi building appears, he runs up to the door and you win. If you crash, you’re “lost in the desert” and start again from Saadiyat.

 

How it works and what I’m proud of

The game is plyed in the following. The player never actually moves forward. He stays in the same spot while the world scrolls toward him, the same trick the dino game uses. Every frame the game updates the speed, score, jumping and obstacles, checks for collisions, and then redraws everything. The jump uses simple gravity. When you press jump he gets an upward speed, and every frame gravity pulls a bit of it away, so the jump curves up and comes back down naturally. Instead of counting frames, the movement uses the time between frames, so the game runs at the same speed on fast and slow computers. The game also slowly speeds up, and the gap between animals grows with the speed, so there is always enough room to land and jump again.

The part I’m most proud of is that everything is drawn with code. There are no images at all. The Emirati man, the snake, oryx, camel and falcon are all built from ellipses, lines, triangles and custom shapes. Animation comes from a sine wave, which makes his arms and legs swing in opposite directions, his ghutra flap in the wind, the snake slither and the falcon flap its wings. Each location also has its own look. Saadiyat has the beach, the sea, dhows and the Louvre dome. Sweihan has camel farms and ghaf trees. Al Ain has Jebel Hafeet, an old fort with the UAE flag and date palms, and Liwa has a sunset over huge red dunes. The scenery is drawn in layers that move at different speeds, so far things move slowly and close things move fast, which gives the world depth. The places also follow the real route you would drive from Saadiyat, and a bar at the top shows how far along the journey you are.

I’m also proud of some game design decisions. The falcon flies at head height, so you have to duck instead of jump. If you try to jump, it swoops up after you, which makes sense for a hunting bird and makes ducking the clear choice. Collisions use invisible boxes that are slightly smaller than the drawings, so you only lose when you clearly hit something. The best score is saved in the browser so it stays when you retry, which brings back the competitive feeling from school, and it resets when you finally make it home so every journey starts fresh. The menu, tutorial and controls screens make it easy for someone new to understand the story and the animals before they play.

. Same speed on every computer. So the movement here is based on the time between frames, and not on counting frames.

// timeStep keeps the game the same speed on fast and slow computers
let timeStep = min(deltaTime / 16.667, 3);

 

. Jumping with gravity. Gravity takes away a little upward speed every frame, so the jump curves up and comes back down.

function updatePlayer(timeStep) {
  if (!player.onGround) {
    player.verticalSpeed -= GRAVITY * timeStep;
    player.height += player.verticalSpeed * timeStep;
    // Landed
    if (player.height <= 0) {
      player.height = 0;
      player.verticalSpeed = 0;
      player.onGround = true;
    }
  }
}

Areas for improvement and problems I ran into

I ran into several problems along the way. The first version of the falcon felt unfair, because it looked low enough to jump over but jumping always made you lose. I fixed this by raising it to head level and making it follow you up when you jump, so losing actually looks right. The music took two to three seconds to start and the crash sound was delayed, because the audio was being streamed like a video. Loading the sound files fully into memory at the start fixed both. My high score also showed 2316 out of 2000 because it had been saved back when the goal was 2500, so I changed how the score is saved and capped it at the goal.

There are still things I would like to improve. I’d like to add lives, so the player gets a few chances before the game ends instead of losing everything on the first hit. I’d also like to make the death scene more interactive, for example by showing an animation of the man falling or the animal reacting, instead of the game just stopping. I’d like to give each location its own animals too, like more camels in Sweihan or snakes in Liwa. Right now the high score only saves on your own computer, so a shared online leaderboard would bring back the real competition with friends. I’d also like to add a pause button and make the controls work better on phones.

References

.Inspiration, the Chrome offline dinosaur game.

.Reference images: Google Images searches for “UAE desert” and cartoon Emirati characters, used for inspiration on clothing, colors and scenery. The final character is my own original design.

.MDN Web Docs, Web Audio API; loading and playing sound files from memory.

.Music “Desert Caravan” by Walen, Free To Use (freetouse.com).

.Distances used to order the route: Bayut Sweihan guide, Wikipedia: Sweihan, Rome2rio Al Ain to Liwa and Rome2rio Liwa to Abu Dhabi.

.The Coding Train, Coding Challenge #147: Chrome Dinosaur Game; how to build the Chrome dino game in p5.js, with a jumping player and obstacles.

.Jumping and gravity: Programming a Retro-Style video game in P5.js, Part 3: simulating gravity and Lesson 2: Simulating Gravity with JavaScript and P5JS: how speed and gravity change the character’s position every frame so he falls back down after jumping.

.Changing scenes: Changing scenes P5 JS: switching between the menu, tutorial, game over and win screens using a game state variable.

.Collision detection: The Coding Train, 8.4 Class and Objects: Collision Detection: checking when the player’s hitbox touches an animal.

.Animation with sine waves: The Coding Train, 3.5 Simple Harmonic Motion (Nature of Code): using sin() to make the arms and legs swing, the falcon’s wings flap and the snake slither.

.Sand dunes and mountains: The Coding Train, I.2: Perlin Noise and p5.js: using noise() for the smooth shapes of the dunes and Jebel Hafeet.

.Saving the high score: Local Storage in JavaScript with p5.js: saving the best score in the browser so it stays after you close the page.

AI  helped me make the Tutorial screen feel more alive. At first I thought of the Tutorial as a page of instructions, but I wanted players to actually see the animals they’d face, not just read about them. Claude explained that each animal’s drawing function takes an animation number, and that number decides where the legs are in their step, how the snake’s body is curved and where the falcon’s wings are. During the game this number goes up as the animal moves. On the Tutorial screen it uses p5.js’s built-in framecount instead, which goes up by 1 every frame. Because the number keeps changing, the snake slithers, the oryx and camel walk in place, and the falcon flaps its wings, all without moving across the screen. This showed me how one variable can bring a still image to life, and that I can reuse the same drawing functions on different screens just by changing the number I give them.

What are some of the ways that computer vision differs from human vision?

The main thing I took from the reading is that computers don’t actually understand what they’re looking at. When I see a room, I just know there’s a person standing there or that it’s night outside. A computer only gets a bunch of pixel values, and it has no idea what any of them mean unless someone programs it to look for something specific. Our eyes also work pretty much anywhere, even in bad lighting or a messy room. Computer vision doesn’t. Levin says no algorithm works in every situation, and if the lighting changes or the background gets busy, it can just stop working.

What are some techniques we can use to help the computer see / track what we’re interested in?

There are a few simple ones. Frame differencing looks at what changed between one frame and the next, which shows movement. Background subtraction compares the camera image to a picture of the empty space, so anything new pops out. Brightness thresholding splits the image into light and dark parts, and you can also just track the brightest spot, like a flashlight. What surprised me is how much the physical setup matters. Using a white background, backlighting, infrared light or reflective materials can make the computer’s job way easier. Sometimes it makes more sense to change the room than to write more complicated code.

How do you think computer vision’s capacity for tracking and surveillance affects its use in interactive art?

I think it works both ways. Tracking is what makes a lot of interactive art fun, because the piece reacts to you and your body, like in Videoplace where your silhouette plays with little creatures. But it’s the same technology used to watch people, so there’s always a bit of an uneasy feeling behind it. Some artists lean into that. In Standards and Double Standards, belts turn to follow you around the room, and Sorting Daemon picks people off the street and sorts them by color. Those pieces made me realize how often we’re tracked without even thinking about it. So for me, computer vision makes interactive art more exciting, but it also means artists have to think about privacy and whether people actually agreed to be watched.

Concept

Back in school, they wouldn’t give us the WiFi password, so whenever I opened a browser I’d get stuck on the “No internet” page. With nothing else to do, I’d end up playing the offline dino game, and it got really competitive between me and my classmates as we all tried to beat each other’s high scores. That memory is where this game started. I wanted to bring back that same simple, addictive feeling, but make it my own by adding my culture to it. So instead of the dino game, I made Desert Runner. The main character is an Emirati man in a kandura and ghutra, and instead of jumping over cacti he jumps over animals from the UAE desert. He runs through real places in Abu Dhabi, starting at Saadiyat Island and moving on to Sweihan, Al Ain and Liwa as the score goes up, before looping back to Saadiyat.

Design

I kept the core of the original game, which is one character, simple controls and a score that keeps climbing, and changed everything around it to feel Emirati. The character wears a white kandura, a ghutra and a black agal. He is drawn entirely in code using simple shapes with black outlines in a cartoon style, and his arms and legs swing as he runs while his ghutra flaps in the wind. Instead of cacti, the obstacles are desert animals. Snakes, Arabian red foxes, Arabian oryx and camels have to be jumped over, while falcons fly at head height so the player has to duck under them.

Every 250 points the scenery fades into a new area, ordered by distance from Saadiyat, and each place has its own look. Saadiyat has the beach, the sea and dhows. Sweihan has ghaf trees and camel farms. Al Ain has Jebel Hafeet, an old fort and date palms, and Liwa has a sunset over huge red dunes. Before playing, the player sees a start menu with Play Now, Settings, Tutorial and Controls, so they can learn the game first. While playing, there is desert wind with an oud-style melody and a darbuka rhythm in the background, along with sound effects for jumping, dying and reaching a new location. The high score is saved automatically so it stays when the player retries, which brings back the competitive side I remember from school.

Challenging Aspects

The most challenging part was drawing the character and the animals with code instead of using images. Everything is built from ellipses, lines, triangles and custom shapes, and the order they are drawn in matters a lot. The back arm has to come first, then the kandura, then the front arm and finally the head, so that each part overlaps the right way. Getting the ghutra to wrap around the head and hang down to the shoulder took a lot of adjusting of coordinates before it looked right.

Making the character actually look like he was running was another challenge. I used a sine wave so his legs and arms swing in opposite directions, his body bobs slightly up and down, and his ghutra flaps in the wind. The same idea brings the obstacles to life: the snake’s body follows a moving wave so it slithers, and the camel’s legs swing back and forth as it walks. Jumping also took some work. I had to give the character an upward speed when the player presses jump, then pull him back down a little more every frame with gravity, so the jump curves naturally instead of moving straight up and down.

The background was tricky too, because I wanted it to feel like Saadiyat Island while still moving. I split it into layers that scroll at different speeds. The sea moves slowly, the palm trees move a bit faster and the ground moves fastest, which creates a sense of depth. Finally, collisions were difficult because the camel’s neck and tail and the snake’s tongue stick out of their bodies. Using the exact shapes would have made the game feel unfair, so I used simpler invisible rectangles called hitboxes to check whether the player has hit an obstacle.

Risk Prevention

Since the game speeds up over time, one risk was obstacles appearing too close together to jump over. To prevent this, the minimum gap between obstacles grows with the current speed, so there is always enough room to land and jump again. The speed also has a maximum limit, so the game never becomes impossibly fast. To avoid unfair deaths, the hitboxes are slightly smaller than the drawings, so the player only loses when they clearly hit something. The player can also only jump while on the ground, which stops them from jumping again in mid-air and floating over everything.

The game starts at a slow speed and gets faster gradually, so new players have time to get used to the timing before it becomes difficult. Movement is based on how much time has passed rather than on frames, so the game runs at the same speed on both fast and slow computers. Pressing the space bar would normally scroll the web page, so I blocked that to keep the game on screen. The game also works with a mouse click as well as the keyboard. Obstacles are removed once they leave the screen so the game doesn’t slow down the longer you play. When the player crashes, everything resets cleanly so they can try again right away.

Concept

My inspiration for this piece came from the Joker. I wanted to take a twist from his personality, that mix of humor and fear where you never know what he’s going to do next, and put it into an artwork. At first I wanted to draw him and have his iconic HAHA laugh be the center of the piece. Then I changed my mind and turned it into a question-and-answer mystery. The piece looks calm and professional at first, with a clean box that says “ASK ME ANYTHING… if you dare.” The moment you ask something, the input disappears, the screen flickers, and a creepy grin with glowing red eyes takes over, laughing that it’s not answering anything. I wanted it to catch people by surprise, because they expect an answer and instead get laughed at, which is exactly the kind of trick the Joker would pull.

Code I am proud of

let t = frameCount - start;
  if (t < 70) drawAsk("Hmm... let me think...");
  else if (t < 100) random() < 0.4 ? background(0) : drawAsk("..."); 
    // flicker
  else drawScary(t);

When the user asks a question, I save the frame it happened on. By subtracting that from the current frame, I always know how long it’s been. First it pretends to think, then it glitches between the box and a black screen, and then the scary face takes over. It’s only a few lines, but it builds the whole suspense of the piece. I also like that the input box hides itself with input.hide(). The user can’t type anymore, which makes it feel like the program has taken control away from them.

How this was made

I made this in the p5.js web editor using JavaScript, and the sketch is split into a few functions that each do one job. In setup(), I create the canvas and build the text box and ASK button with createInput() and createButton(). I styled both with .style() so they match the black and red theme. The ask() function runs when the user presses Enter or clicks ASK. It checks that the box isn’t empty, saves the current frameCount as the start time, switches the mode from “ask” to “scary”, and hides the input and button so the user can’t type anymore.

The draw() function uses that saved start time to move through the stages. For the first 70 frames it shows “Hmm… let me think…”, then it flickers randomly between the box and a black screen, and after that it switches to the scary scene. After a few seconds it resets and shows the input again. The drawAsk() function draws the title and the rectangle and makes the message type out letter by letter. It does this by increasing a counter each frame and using substring() to show only part of the text. Finally, drawScary() draws the glowing red eyes with ellipse() and the jagged grin with a loop of vertices using sin() to curve it. It also shakes the whole screen with translate() and random values and fades everything in by raising the transparency over time.

Reflection

Response

Something that drives me crazy is the newer car door handles, like the ones on a Tesla. Most of us grew up with the same idea of how a car door works. You grab the handle and pull. The newer handles break that idea completely. There’s nothing sticking out to grab and no clear sign of where to press, so people end up standing at the door confused about how to get in. I think part of the problem is the design, because it chooses a sleek look over being easy to figure out. But part of it is also just habit. People have used the old handle for decades and it works for them, so any change takes time to get used to. Maybe one day people will find the new handles normal and the old ones will feel strange. Still, I don’t think we should just wait for everyone to adjust. A small cue like a subtle dent or a light showing where to press would help a lot, and the design could still move forward while respecting what people already know.

Norman’s ideas fit right into interactive media, because making an interactive piece is really just another kind of design. When I make an interactive artwork, the way I picture people using it is often very different from how they actually see it. That’s the same gap Norman talks about between what the designer has in mind and what the user understands. I can’t stand next to every person and explain my work, so the piece has to explain itself. That can mean the cursor changing or something reacting when you hover over it. It can also mean giving feedback so people know their click did something, or making movements feel natural, like moving the mouse up to make something rise. After this reading I always ask myself two questions when I make something. What are its signifiers, and what idea of how it works does it give the person using it?

 

click to change scene

Concept

 

 

 

 

 

 

The idea came from jet skiing, which I do casually, so I already had a clear picture in my head of what the water looks like from the seat, the way the surface keeps moving underneath you and the horizon never sits still. I also took inspiration from the car example that was posted for the class. That example uses a simple object moving across the screen against a background, and I used the same basic structure here, but replaced the car with a jet ski and the road with a moving sea.

I extended the idea in two ways. The first is the water itself; instead of one flat background, the ocean is built from four Wave objects stored in an array, each one drawn lower, darker and moving at a slightly different speed. Drawing them in order means the closer waves cover the ones behind, which gives a sense of depth, and the topmost wave doubles as the horizon so the sky meets the sea along a curve rather than a straight line. The second addition is time of day. Clicking the canvas switches the whole scene between daytime and nighttime, changing the sky and water colours and swapping the sun for a crescent moon with stars behind it. I wanted the piece to have more than one state so there was a reason for the viewer to interact with it rather than just watch it.

How it was made

The sketch is built from four classes: Wave handles one band of water, Bubble is a small circle that floats upwards, Star is a dot in the sky, and Jet ski draws the craft and its rider. Each class stores its own values in the constructor and has its own move and display methods, so the draw function stays short; it just loops through the arrays and tells each object to move and draw itself.

The objects are created once in setup using for loops and stored in three arrays: waves, bubbles and stars. Doing it this way means I can change how busy the scene is by editing a single number. Asking for seventy stars instead of twenty is one character in a loop condition, not seventy lines of code, and this is the main reason the program uses objects and arrays.

The most important part of the code

beginShape();
    vertex(0, height);
    for (let x = 0; x <= width; x += 10) {
      vertex(x, this.y + sin(x * 0.02 + this.offset) * this.waveHeight);
    }
    vertex(width, height);
    endShape(CLOSE);

This builds one wave as a single filled shape. The loop walks across the canvas and places a point every ten pixels. The height of each point comes from sin, which rises and falls smoothly between -1 and 1, so multiplying it by the wave height turns that into a rise and fall measured in pixels. Adding the offset shifts where the curve starts, and because the move method increases that offset a little every frame, the whole wave appears to travel sideways. The two extra vertex calls at the bottom corners close the shape off so it fills downwards instead of being just a line.

What makes this the key part is that everything else in the artwork depends on it. Each Wave object is given its own wave height, speed and starting offset, so the same six lines produce four waves that all look different and move at different rates. That difference in speed is what creates the sense of depth, since the nearer waves move faster than the ones further away. Without this one piece of code the scene would just be flat blocks of color.

Reflection

The hardest part of this project was not writing the classes themselves but getting the layers to sit correctly on top of each other. My first version drew the sky as a plain rectangle ending at a fixed height, and the result looked wrong straight away; there was a hard straight line cutting across the middle of the canvas where the sky stopped, which broke the illusion completely. I fixed this by changing how the background is built. Instead of drawing a sky rectangle and a water rectangle, the sky color now fills the entire canvas and the waves are drawn over the bottom half of it, with the topmost wave acting as the horizon. Because that wave is made with sin like all the others, the edge between the sky and the sea is a curve rather than a straight line, and the whole scene reads as one thing instead of two blocks stacked on top of each other.

Looking back, most of my difficulties were about order and timing rather than logic; which order things are drawn in, when the canvas gets cleared, and when an object is moved relative to when it is visible. The classes and arrays were the straightforward part once I understood that a class is written once and an object is created from it many times. If I were to take this further I would like the jet ski to actually sit on the surface of the wave and tilt with it, rather than bobbing independently, since that is the one part of the scene that still gives away that the jet ski and the water are not really connected.

Reflection

I think a strongly interactive system has to respond quickly and meaningfully to whatever the user does. Speed matters a lot, because if there is a noticeable delay between my action and the system’s reaction, the loop breaks and it stops feeling like a conversation. It should also accept a wide range of inputs rather than just one, and produce output that is fun and exciting to receive: sound effects, motion, color, and visuals that reward the user for engaging. Using Crawford’s framework, a strong system has to do all three steps well. It has to listen properly by capturing what the user is actually doing, think by shaping its response to that input rather than repeating itself, and speak clearly so the user can tell their action caused the result. Reliability belongs here too, since bugs and crashes break the cycle completely and a system that stops responding has stopped interacting altogether.

The other characteristic is the user’s own willingness to explore. Someone eager to poke at a system will have a far richer experience than someone who isn’t in the mood, even with identical software. A good system invites exploration by making its possibilities visible and by rewarding the first thing the user tries, which is what pulls them into trying the second.

For my own p5 sketches, my main idea is to widen the range of inputs they accept. At the moment I rely on a narrow set, so I want to make more use of the cursor; not just clicking, but position, speed, and dragging, so the sketch is continuously responding rather than waiting for one discrete event. I also want to use clicks to transform the artwork, so that each click shifts the sketch into a different look or state and gives the user a reason to keep going. Beyond that, I would like to experiment with 3D, since being able to rotate and look around a shape hands the user real control rather than just something to look at, and to play with motion that reacts to the user instead of looping on its own; if the direction or speed of movement responds to where the cursor is, the sketch is listening continuously instead of just performing.

Concept

I grew up around my father’s paintings, he is a cubist, so when this assignment asked for a work of art made out of loops, my first instinct was to try and get something of his work into it.

His paintings have a similar touch. An Emirati figure in traditional clothing, but the face is never a face. In one it is a Pepsi cap and a cola glass. In another it is a Jumeira Road sign with a traffic light on top. In a third the whole scene is an arcade cabinet, Pac-Man and Space Invaders. The body stays traditional and the head is always something imported. That contrast is the thing I wanted to borrow.

What I ended up making is a hand doing the three fingers salute that H.H Sheikh Mohammed bin Rashid does three fingers up for win, victory and love. The whole canvas is broken into irregular shapes that slide up and down against each other, the way a cubist face is broken into planes that do not line up. The hand is made of exactly the same shapes as the background, so most of the time you cannot see it at all, I also got inspiration from one of the sources to create an illusion effect with the hand and implemented it.

Then it comes out. And as it appears, it also stops moving. Everything around it keeps sliding but the hand holds completely still. It is the one fixed thing in a field that never settles. Then it fades back in and rejoins, and comes back in the next color of the flag; red, then green, then white, then black.

Code Snippet

quad(
       x + random(-j, j), y + random(-j, j) + d,
       x + s + random(-j, j), y + random(-j, j) + d,
       x + s + random(-j, j), y + s + random(-j, j) + d,
       x + random(-j, j), y + s + random(-j, j) + d
     );

This part of the code is where I was most proud of, creating those irregular shapes and making that motion of sliding against each other with the slide function, it took time and effort searching through references and working with the p5.js tutorials but I was finally able to get it. The quad() is what makes the shapes look shattered instead of like a grid. If you take out all four random() calls you are left with the plain corners of a square: x, y then x+s, y then x+s, y+s then x, y+s. Adding a small random nudge to each corner is the entire difference between a pixel grid and something that looks like a broken plane. That was the closest I could get in code to how my dad breaks a face into flat angled pieces.

Embedded Sketch

 

How This Was Made

This was made with a lot of references that were new to me. Most of them came from the p5.js reference site, where I found quad(), noise(), randomSeed(), lerpColor(), constrain(), and abs(). Each one ended up doing a specific job.

. quad() is what let me draw a four sided shape with corners anywhere I wanted, instead of rect() which is always a right angled box. Without it there is no fractured look at all.

. noise() gave me smooth randomness rather than the jumpy kind, so neighbouring facets get similar colours and the background reads as planes instead of static.

. randomSeed() solved a problem I did not see coming. The shapes flickered violently until I understood that random() runs fresh every frame, and resetting the seed at the top of draw() makes every facet keep the shape it had.

. lerpColor() mixes two colours by a proportion, which is what lets the hand fade out of the background rather than being switched on and off.

. constrain() clamps a number between two limits. I used it to flatten the top and bottom of the sine wave so the hand holds still at each end instead of permanently mid fade.

Reflection and Future Work

The thing I did not expect is how much of the piece is decided by numbers rather than by drawing. I never drew a hand. I wrote six conditions and tuned numbers until the silhouette matched a photo. That felt strange at first and then it felt like the point.

It also lined up with the Reas talk more than I thought it would. The shapes are random, but I chose the palette, the grid size, how far a corner can wander and how fast the fade runs. The randomness does the part I could not be bothered to do by hand, and it produces small irregularities I would never have thought to draw. That is the balance he was talking about.

For the future, I would use the mouseX to control how far the shapes wander, so the viewer decides how broken the image is, make the hand disappear in a better fade look than just fade without a proper effect.

 

Reflection:

After watching Casey Reas’ Eyeo talk, I found it very close to my own thinking. I grew up with an artist as a dad, and not just any artist, a cubist. What is cubism, you may ask? It’s a unique and funky type of art that blends different shapes and can be read differently depending on the angle you look at it from. The kind of cubism I grew up seeing also packed ideas, experiences and emotions into a single painting, leaving the viewer to guess what is going on and to find an angle nobody else had found.

That shaped how I look at art. My dad used to bring his work home and make me guess what was happening in it, so I learned to read a painting emotionally and from a perspective different from everyone else’s. This is why the talk resonated with me: art is not cold or unemotional. Every piece carries its own meaning and its own way of thinking about how the artist wanted it to reach people. What’s funny is that sometimes I would see something in his work from a perspective he hadn’t considered himself, and that is exactly what makes it beautiful.

I intend to use randomness to give my work the spark it needs. Random motion in one of the shapes, or a sudden loop of shapes overlapping the piece, could make it better than it already was. It would also create a kind of illusion, pushing viewers to think more deeply about the work instead of just staring at a controlled image, and having the viewers look at my art at different angles.

As for the balance between randomness and control, I don’t think it’s something to stress over. Writing the code is the same exchange I grew up watching: you set the rules the way my dad set his shapes, and what comes out can still surprise you, just as I sometimes found things in his paintings he had never intended. Control gives a piece the stamp of the artist’s own style, while randomness can push it somewhere nobody imagined. A piece can look like it only has one way of being seen, but the beauty comes from people finding perspectives the artist never did.

 

Concept:

My concept for this self-portrait was to represent my culture and background through p5.js. I wanted to express myself as well as the city I was born in, so I included the Burj Khalifa in the background as a distinguishing landmark. I represented myself through the traditional clothing called the Kandura, which is what I mostly wear on a daily basis, as well as the ghutra, which is wrapped around my head. My beard also played a big part in this self-portrait, as I believe it’s one of my most distinct features. I also wanted to experiment with animation, which I was inspired to do after seeing our previous class samples.

How this was made:

This self-portrait was made with p5.js, using a variety of features such as arcs, rectangles, ellipses, fills, and strokes. Arcs were used for the mustache, beard, mouth, and ghutra, while rectangles were used to build the Burj Khalifa and form the neck. Another interesting thing I found was the beginShape() function since I didn’t want the kandura locked into a fixed shape like a rectangle, I wanted to stretch it a bit to look more natural, and this came in handy for that.

The Burj Khalifa, on the other hand, was formed with simple rectangles at different points and sizes, which was a bit annoying to do, as I had to play around with different coordinates to get it the way I wanted. Another part where I felt a bit stuck was forming the ghutra, as I didn’t know how to shape it, so looking at previous students’ work really gave me the inspiration to visualize how I wanted it to look.

Another thing I wanted to make stand out were the eyes, especially adding the white dot next to the pupil to make them more lively and easier to look at.

A challenging part was implementing the animation for the self-portrait, as I was clueless on how to start it, but I was able to use if/else statements to make the blink and eyebrow expression happen in unison as you hover the mouse over the eyes. I looked at a few tutorials as well as AI to figure out the whole concept and apply it to my work.

Code I am Proud of:

function draw() {
  
  // Burj Khalifa
  fill(150, 180, 215);
  noStroke();
  rect(430, 340, 100, 260);
  rect(441, 210, 78, 160);
  rect(452, 105, 56, 110);
  rect(463, 55, 34, 60);
  rect(476, 25, 6, 30);

This snippet of code is the one I am most proud of, as it forms the Burj Khalifa, the finishing touch for my self-portrait. I kept thinking of different ideas for a background, but it had to be the Burj Khalifa. I was overcomplicating the code for it, as it wasn’t easy to grasp because its design is unique compared to other buildings. But then it hit me, it was much simpler than what I had made it out to be. After thinking about it for over an hour, the actual work was completed in just two minutes. I just had to add rectangles one over the other, reducing the size each time it ascends. Playing around with the coordinates was a bit annoying, but worth it in the end.

Reflection:

Working on this self-portrait taught me a lot about both p5.js and my own patience. Going in, I didn’t have much of the design experience, so just understanding how shapes like ellipses(), rect(), and arc() worked together to build a face felt overwhelming at first. Breaking the portrait down into small, separate pieces; the head, the eyes, the beard, the ghutra, made it much more manageable, since I could focus on getting one feature right before moving on to the next instead of trying to solve everything at once. The parts that meant the most to me were the ones tied to my culture: the kandura, the ghutra, and the Burj Khalifa. I wanted the portrait to say something about where I’m from, not just be a technical exercise, so getting those details right mattered more to me than getting the code perfect on the first try. The ghutra in particular took a few attempts to get looking right, and I leaned on classmates work and some trial and error to figure out how to shape it convincingly. Overall, this project pushed me to combine a personal, cultural concept with a completely new technical skill, and I’m happy with how both sides came together in the final piece.