SCRUB LOVE is a virtual scrubbing experience for two people to connect nonverbally, based on a Korean bath house culture.

Going to a public bath house is fairly common in Korea. Oftentimes at a bath house, people scrub the backs of their loved ones, as it’s difficult to reach your back with your own hands. I wanted to emulate this affectionate experience on a digital platform, to help people connect in remote circumstances.

Experience for yourself here.

Full Code

For this project, I created a (2) synchronous, and (3) equal experience for two people. As my project was a fictional interpretation of a very tangible, physical experience, I had to do enough revising to capture the essence of the experience under the affordances of digital media.

I achieved this by having two people scrub each other’s back synchronously and at equal positions, rather than making one scrub the other’s back asynchronously. As synchronous back-scrubbing between two people is impossible in real life, I think the digital experience became something unique on its own, transcending beyond a digital replica of the physical experience.

Overall, I’m satisfied with the final product, as I was able to maintain the original intention from start to finish. Figuring out the right animation for the noodles was really difficult, but the experimentations paid off in the end.

My initial ideas: I had around four ideas in mind, based on what I thought would be a delightful experience:

1. “Don’t look at me!” –  Every user is a person in a bath. If your eyes dart towards someone else’s body, you get some sort of punishment. Based on the awkward experience of being naked and being surrounded by other naked people in a Korean bath house.
2. “Flashlight cursers” – Every curser has a yellow ball of flashlight. Once enough cursors cluster, it reveals an image hiding behind a black screen.
3. “Bike together” – A collaborative, side-scroller biking experience. Every user bikes on a “chain of bicycles” (like an extended tandem bike), jumping and avoiding obstacles by angling the phone. If one person fails to avoid the obstacle, the entire group fails the game.
4. “Scrub together”* – A collaborative scrubbing experience. Based on a culture of scrubbing loved one’s backs in a Korean bath house.

I ended up following through with the fourth direction, after receiving some positive feedback from my peers on the idea.

Screenshots from my process

I tried out various different ways to animate the noodles. I ultimately chose to keep the noodles short and squiggly, for the right balance of a noodle and dead skin.

Too noodle-like:

Too dead skin/worm-like:

*For reference, this is what the back scrubbing would look like in real life:

This project allows users to collectively cook and eat a stew with their friends.

To address the local versus remote principle, this project is made for people far away. Cooking is an intimate task of creation that requires being in the same place with resources. During quarantine people who would cook together can’t. This is to help simulate that bond.

My process:

• made the sketch
• made some assets
• pulled them up and fixed the orientation and interaction
• added the ability for other people to contribute to the soup

My sketch:

 

 

 

 

 

 

 

 

 

Project Gif:

 

 

 

 

 

 

 

game link:

https://collaborative-kitchen.glitch.me/

this is a two person game. Crash the server with this link:

https://collaborative-kitchen.glitch.me/?crash

video:

 

Ever since the pandemic has started, I haven’t got much chance to go out and meet with my friends yet, neither have I went back to Shanghai (and possibly won’t until next year). So, I created “ROOM WITH A VIEW” – a sharing tool for people to share the views from their windows (or from any other places people would like to share) with their friends and families in virtual apartment cells.

Each user gets assigned to an apartment cell with their local time and time zone displayed at the sides of the room. Users can share their live stream videos via this pixelated window to others. The wall colors of the rooms are mapped to the local time zones of each user. Besides from the live stream, users could also move around the touch screen to animate the clouds ☁️

Code | Demo (right now only works for desktop webcams and mobile front cameras)

This app allows users to create a drawing by requesting various drawings from another user.

https://youtu.be/TT9Irxqh7PI

The app works by using firebase (an online database service) to store drawings and associate them with the user (each user signs in anonymously and is given an id tag).  Each request is also stored in this database. Each time the drawings are updated or the user switches from their drawing board to their canvas, the program checks the creator of said drawing and only draws the drawing on the canvas if it was not created by said user.

Overall, making this app was very challenging. I think I could have simplified my idea a lot more and gotten a much more successful outcome. Though the app does generally what it is supposed to do this comes at the expense of nice UI and presentation.

 

TRON RACER

TRON RACER is a networked game in which players can leave trails as obstacles which deduct opponents’ lives. ( APP | CODE )

TRON RACER was definitely a challenging project to complete. I was inspired by the light bikes (original, legacy) from TRON. From getting the interaction of tilting to behave correctly, to making the global and client view's look aesthetic and accurate, there were plenty of programatic roadblocks. Since it is a game, the interaction is active and synchronous. However, establishing equal synchronicity was quite interesting because certain devices have higher frame rates, which allows more distance to be covered in the same amount of time as a device with a slower frame rate. To compensate this, I learned how to update the clients based on time rather than based on frame rates. As it is now, I enjoy the aesthetic of playing TRON RACER, but there are still some bugs with some client devices appearing too zoomed in.

Documentation

sweetmail

Sweetmail is a messaging platform similar to email but more intimate. It runs on voice commands, as there is something special about speaking the words “I Love You” or any other expression of affection in comparison to typing the words. It is designed to be used asynchronously among however many people find this platform meaningful. This allows for you to express your affection whenever you feel it, to whomever you feel it towards.

I think the use of voice recognition is inconvenient and obtuse to many, but implementing typing on mobile websites was even more inconvenient and obtuse. I would also have been unable to use Lingdong’s p5.hershey.js. The inaccuracies of speech recognition are much like natural communication in relationships. Holding ourselves to perfect transmission of our ideas is unrealistic and can be overwhelming.

Letters are stored using lowdb and users are only shown the letters written to them. I’ve written a letter to everyone in this class using their course nicknames. If you have an odd spelling or the program isn’t recognizing your username, try spelling it letter by letter.

Shake2Break 

( code | app )

Shake2Break is a quick competitive phone shaking game that could be used to solve a minor dispute by deciding the rank/order of people. (2 players required to play)

Project Reflection:

This project was a nice opportunity for me to learn how to implement client data / server data in server.js, as well as how to utilize sensor data from a mobile device. Although I was initially intimidated by the idea of using server.js and mobile sensor data (as I’ve never used nor seen a code for either of them before), I found implementing server.js and manipulating mobile sensor data very interesting and fun to play with. Since it’s my first time using those, I wanted to begin with a project that is simple yet to the point: an active synchronous shaking game. The server requires two players synchronously present to begin the game. Once there are two players, the competition begins, where each player can shake their mobile device back and forth to engage with the accelerometer inside the device, specifically the accelerometer data along the z-axis.

Demo Video:

Demo Video with Animation Intro:

Game Start:

Each shake is counted only when the player shook the phone “hard enough” (i.e. the acceleration in the z-axis is greater than 70). The circle’s radius is drawn in the intention of helping the player visualize the acceleration of the phone.

There are 10 rounds of 10 counts to fulfill (hence total of 100 shakes), and the progress of the player is both numerically and visually (filling up the square) represented.

As a player, you could see both your progress (indicated as “ME” on the top left corner), as well as that of the opponent’s.

Mid-game:

(Shaking each phone very hard…)

Game End:

Once the player reaches 100 shakes, the rank is assigned and shown based on who has reached 100 counts first.

Sketches:

^(initial ideation of the project)

^(project sketch)

Summary: A digital pet co-parenting app

https://glitch.com/~doggo-simulator

This project is ... 

This app targets couples who are thinking of getting a dog, and I was inspired by my own concerns over couples adopting / purchasing dogs in the midst of covid loneliness. I am afraid that a lot of pets will be abandoned once the virus is no longer present, and people's lives will be back to normal. A lot of people have no real idea of the work behind taking care of a dog, so I wanted to have this experience simulation that let a couple recognize if they are both ready for the responsibility.

My Reflection on this Project

I had a lot of fun making this project, and creating the assets for the interface, also the exposure to backend server and database was much appreciated. I always wanted to explore backend but procrastinated to do so until this project asked me to! Overall I'm pretty happy with how it turned out given the time constraint of the project.

My project touches on mainly touches on the following theme: Asynchronous vs. synchronous: Do the two people collaborate simultaneously, or at different times? By design, it is most likely that people will be collaborating asynchronously in this app, remembering about their digital pet at different times throughout the day. The record keeping feature highlights how many times did they each individually contribute to the well-being of the digital pet.

Selected Assets 

 

 

 

Snail Mail allows users to deliver messages one character at a time, once an hour.

My project is definitely a critical reflection about communication, specifically texting. When approaching this project, I thought about how I could change text messaging to make messages more meaningful. I consume so much media that I sometimes forget what a text says immediately after sending/reading it. Originally, I planned on making a messaging app that allows users to send only one message per 24 hours. Additionally, I wanted users to wait 24 hours to see their message. I simplified the execution of this concept while focusing on making texts more precious/rare and text messaging more archaic.

Under the current texting system, many people fixate over the time it takes someone to respond to their message or the amount of texts someone sends them and try to extract meaning from those behaviors. I wanted to create a simpler form of texting with less fixation.

Other sketches are in the form of written notes, here are some:

• • messages slowly revealed over 24 hours (simple animation, e.g. text fade in)
  • reward users for waiting 24 hours to open the message
  • record voice memos that are delivered years later

Snail Mail (Currently set to deliver once every 2 minutes and only works on my laptop)

gnome telematica by mokka

A garden gnome hangout! This idea was inspired by my very own friend’s obsession with gnomes, especially in the Animal Crossing: New Horizons game. I dedicate this to her.

I wanted this project to be synchronous in that you can immediately interact with those who are also on the app alongside you in real-time. It should be able to function remotely as its purpose is to be able to interact with people across the world; however, I did put a limit to only 3 people(likely to change). I would like to have this as a concept of safely saying hello to anonymous people, but that is all they can do… hang out with each other. In this way, with a smaller group, I believe a sense of curious intimacy can happen rather than a large group of users. All users have equal roles which is just dragging their finger around the grass acknowledging the presence of each other.