project link

Preface

Here is a detailed blog post about my design on (Un)Faced. If you are only interested in the final showing condition, you can go to the simplified blog or GitHub page. The following content in this blog post will include my Design Process, Coding Process, Reflection & Future Development, and Credits & Reference.

Design Process

(Un)Faced is a scrolling story about identity and conformity in a future ruled by masks. 

You are a member of "We": You are the same, non-deviant, and always safe with your mask on—no fear of being different as "yourself." However, when your mask falls and reveals a void, your journey to rediscover the self begins. 

scene & transition design

scenes (chapters)

It should be noted that each chapter may have different scenes to organize different layers and assets. It is controlled by a global state with different boundaries for different scenes, which will be further explained in the coding part. This ASCII-style art flowchart is generated by AI, but I filled in every slot manually myself.

transition

 Looking into the mirror was designed to be perfectly connected to the end of each chapter as a smooth transition, but given the time limit, I chose a separate "transition mode" that allows "me" to go back to a spiritual world. Thus, I could avoid complex 3-D room building for a reasonable appearance of mirrors, yet still mark a new step in the whole story. 

Each transition starts with the eyes blinking to simulate the situation of “waking up in a new environment after fainting.” In fact, the transition room represents where the "self" is stored deep in "my" heart, and entering the transition room means experiencing a new step of self-exploration. Thus, each time "I" look into the mirror (after a period of "Chapter" self-exploration), my face will be clearer.

Self-awareness identification

I have three identifiers for the recognition of self-awareness designed for (Un)Faced. Color (or complexity), art style, and mirror image.

Color & Complexity

The first chapter starts with black and white, with simple lines and shapes. It becomes more complex with more color in the following chapters. For example, in Chapter 2 (Escape), when viewing "myself" on the map, it is light red at the entrance, and totally red at the exit. Refinding "color" also means rediscovering self-awareness.

art style

I used the "hand-drawn" style to refer to the "world inside the mirror," while the realistic style was for our real life. Since the first transition implies stepping into the mirror world, all the following chapters happened with the "hand-drawn" style as a whole, and other realistic images are inserted in the form of a magazine collage to create a sense of absurdity.

mirror

Every time I look in the mirror, my face becomes a little bit clearer. Mirror is also what I have put in the Time Capsule for the final presentation.

Detail: sound effect, Default page

I have made sound effects for the key scenes where the audience might not know how to operate. For example, at the beginning of each transition, I inserted the sound of a heartbeat. It is because the eye blinking will only appear when the audience starts scrolling, while the default transition page is all in black. The sound effect is used to remind them that it is not a webpage or network error; instead, their interaction is needed. I have also used sound effects to make something not implemented visually more vivid; for example, in Chapter 1, when the user clicks on the red button, the door opens. However, I was not able to draw a 3D opening process with p5; thus, I chose to use sound as an alternative.

My initial default page was implemented with a FaceMesh consisting of flashing characters. And the initial design was that when clicking, the characters "condense" to form a mask, which could lead to a smooth transition to the first chapter with a mask on. This idea was eventually given up due to the page lag caused by insufficient performance with the machine learning model.

Coding Process

overall structure & lifecycle flow

core Flow

state machine

INPUT

Input routing is defined in input.js: mouse wheel controls scroll or transition time, which is defined in the global state as state.currentScrollingPosition (in Chapter/Scene), or state.; click starts story or triggers door; keyboard is only used for chapter 2 as an alternative to scrolling on the x-axis. More detailed explanation could be found in the code image below.

OOP - Transition & Scene

The transition class is way more complex than the Scene class because the rendering logic of all transitions is almost the same, and they are implemented as methods for inner rendering and calling. Only slight changes would be made by the current transitionCode. However, the render functions for different scenes are different from each other, and they are defined separately. Thus, the rendering function for different scenes could be attached to them respectively.

Specific scenes

walking in the room

I have to admit that the update function of my self-defined Rectangle Class is a bad design: it takes the global variable (current scrolling position) as the calculating dependency. It should have been changed to pass-in parameters

scene ME

SceneMe runs on a separate layer that holds the “W” and “E” letters. Everything, including letter position and physical variables, would be used later. Inside SceneMe, each frame would update the current physical variables by integrating air friction, wall bouncing(damping), and updating the current letter positions. Moreover, Qualified bounces that are fast enough and spaced by 500 ms would increment sceneMeBounceCount and gradually rotate the W up to 180° to form "M". The time period is set to prevent the numerous impacts in a short period of time in a corner. 

Technical challenges & future improvement

Bad Project Organization: (Un)Faced is a rather big project compared to my former mini-projects. I started it with less preparation and wanted to organize all the visual elements by scenes. However, I found that only scenes could not solve the problem because of my scene's boundary settings. Then I introduced the "Transition" class to be inserted between scenes. It worked, but destroyed my original architecture and forced me to rebuild the project with extra structures. Then I continued developing the following modules in different files, which led to a mess in the end. I had to reorganize all the files after completing the project to make sure my technical explanations resonable.

I hope that in the future I could write the storytelling first, and then decide on a rather defined and available framework, and finally develop the whole project inside this structure, instead of developing while writing the script.

Edge Case Protection: the scrolling feature of the mouse makes the global state.currentScrollingPosition changes without expectation since even when I stop scrolling, there might still be an inner inertia changing without interaction. Referring to my former code in the INPUT explanation, you can find that there are many "if" and "return" flow controls in the mouse wheel function. It was because I did not design a method to accommodate all edge cases, and scrolling back and forth would frequently lead to bugs. Therefore, my current design is to prevent all possible bugging conditions manually, but further development would still invent new edge-case bugs. I think it could be addressed by editing the inner properties of the Scene class by constraining in-scene data changing.

Reflection & Future Development

Feedback & future IMPROVEMENT

1. The concept of "Mask" should be used more frequently. The mask class was the first OOP element I used in my code in my very initial and ambitious proposal. However, only the beginning of the first chapter used this class in my final version.

2. More interaction: I hope more interaction with the keyboard could be implemented. Currently the keyboard is only used for Chapter 2 Escape for those who cannot use a touchboard for movement on the x-axis.

3. 3D scenes with WebGL (not only simulating a 3D first-person camera using 2D graphics): I think the non-completion of my original proposal should also be explained by the difficulty of 3D programming with native P5. Since WebGL could be integrated into the whole canvas, I think it might also be a better choice to use 3D modeling and a first-person camera for the room transition and scene building.

4. Smooth transition and consistency (Feedback): I chose to continuously enlarge a certain element for scene-to-scene transition, such as the map in the second chapter, the "WE" identifier in the third chapter, and the mirror in transition. It might not be smooth and would lead to misunderstanding, which can be improved using the true 3D scene building mentioned in the third point.

5. Longer storytelling on "exploration" and less transition length (Feedback): due to the ease of reusing, my narrative is largely composed of transitions, while chapters, due to their developing difficulty, are simplified into 2D mini-games or purely scrolling interactive scenes with minimal scene changes. I hope to enrich the script content and make the stories in the chapters more attractive.

Credits & Reference

Other Hand-drawn asseets

final presentation slides