2
If you search for “rhythm game proposals” on Bilibili, you’ll see many videos with new mechanics, yet most projects fade within a year. I kept wondering whether my own ideas would end the same way and how I should take responsibility if others joined me.
This question stayed in my mind when I began developing “Domain Echoing” with more care. I began by studying many rhythm games and comparing their systems. I wanted my design to feel fresh, and I wanted every decision to have a clear purpose. I then spent one to two months building a small demo to test whether the project could work. I created a timing system that used BPM to generate beat intervals, which kept the animations aligned with the music. I largely focused on this part because accurate timing almost shapes the entire feel of a rhythm game.
Soon, I realized that timing was only the foundation. I needed to create a sense of impact, the sound of each tap, the way notes appeared, and the clarity of the visual effects. I tested each detail many times. The hit sound needed the right tone, and the effects needed to guide the player without overwhelming the screen. I understood the difficulty only after adjusting them myself. That feeling of “touch” came from many small choices working together.
I uploaded my demo once it felt natural to play. Several people contacted me with interest, and we completed the full game together. Through this process, I learned how to guide a project from an idea to something real.
Experiences like this changed how I work. I usually start with simple research, try my ideas early, and make progress step by step. This habit helps me figure out which ideas are practical and which ones I should put aside. It also gives me a steady direction and reminds me to respect the time and trust my teammates give me. I see game development as a shared effort, and I want to stay responsible for the people who work with me and for the project we build together.
3
“I wanna learn music composition, do you have any advice?” “Sure: start with music theory, and the rest gets much simpler.”
I’ve heard that countless times. Tutorials, Reddit threads, YouTube comments…they all say the same thing: learn the rules first, then break them. But I never really started that way. I’d argue real music composition isn’t about any of that; it doesn’t rely on fixed tracks to decide how elements should be arranged. It depends on one thing: QUALIA (the pure feeling of sound).
After a long day at school, I head straight to my room and boot up my computer. In my quiet room, the only sound is the desktop fan. I load a piano plugin, click in a few notes, and play them once. If something sounds off, I change it until it feels right, a little better each time. Like a looping algorithm, I keep breaking and rebuilding until it finally fits.
That feeling is where everything begins for me. When I compose, I don’t think in chords or keys first; I think in the overall feel, how those emotions surge, and how the arrangement carries them. Sometimes I don’t know how to express those emotions, so I listen to other people’s music to see how they do it. I even tried imitating a composer almost obsessively, playing their track at 0.75× speed and dissecting every sound that appears. Through this process of trial and error, I eventually found a stable way of working that lets me turn out better music. Others might follow their teachers’ templates, but I’m self-taught, and apart from relying on the melodies I carry in my head, I have no “recipe” to follow.
I like to improvise, not because I reject structure, but because it keeps creation alive. It doesn’t conflict with my urge for perfection; it grounds me in the process. As a creator, I know that when I start noticing flaws in the works I once felt proud of, it means I’ve improved. I may never create perfect music, but one day I’ll create something that truly moves people.
6
My interest in computing began with games, but it’s grown into something much more. I’ve been playing games on a computer since kindergarten, mostly simple ones like Angry Birds. Back then, I had no idea how these games were created; the computer was just for fun. It wasn’t until I stumbled upon Dancing Line in elementary school, by chance, that everything changed.
I came across countless fan-made levels online and thought, “If other players can create these, why can’t I?” So, I dove into tutorials. In 2019, I was a complete beginner, and it could take hours to find the right resource. Many creators showcased their custom levels, but few shared their source code. Eventually, I found a video that briefly explained the code, and it used Unity. I downloaded it, though I barely understood what was happening. All I could do was copy every line of code, word for word.
After a lot of trial and error, I got the line in-game to move and the collision system to work. It might sound simple now, but for me, it felt like a breakthrough. After that, I kept following tutorials, learning by copying, and slowly, the code started to make sense. My programming journey began with copying, and from there, I started making things of my own.
Later, while downloading a Minecraft mod, I discovered GitHub and learned to use it. I continued making Dancing Line levels even after the game stopped updating, and by 2023, I was building my own indie rhythm game. Through these projects, I developed a solid set of programming skills.
Games have shaped 90% of my computing ability, and they changed how I think about technology. When I write code now, whether it is for a small tool or a school project, I still follow the same pattern: observe, take something apart, and rebuild it, and learn from each mistake. This process is what I enjoy most about computer science. I want to keep studying this field so I can move beyond games and explore ideas that I haven’t been able to reach on my own.
7
The most meaningful thing I’ve done for my school began with a simple observation: our cafeteria couldn’t breathe. By lunchtime, the line stretches so tightly that people can barely move, and getting a simple meal can take much longer than it should. I had stood in those lines for years, but I never thought about them until AP Research pushed me to find a topic close to my daily life. I read a sample paper about improving a school’s lighting system, and it made me notice how much detail hides in ordinary spaces. With that in mind, I started seeing the cafeteria differently.
After my instructor approved the topic, I started collecting data. Because of school privacy rules, I had to count every student by hand through the surveillance screens. The monitoring room was unheated in winter, and the plastic chair felt colder each day. Still, I sat there after class, recording the flow of students as if I were tracking the pulse of the building. The screens looked quiet, but each figure that entered or exited added another mark to my notebook.
Back in the classroom, those marks turned into a queueing model. Students became arrivals, service rates, and waiting times, but in my mind I still pictured the familiar lunch crowd shifting forward step by step. When the model finally showed clearer patterns, my advisor encouraged me to share the results. I sent the report to the principal.
To my surprise, I noticed that the serving schedule had changed, and the line flowed with fewer stops than before weeks later. The cafeteria was still small, but its “breath” felt steadier. I later learned that the school had adopted several recommendations from my study.
In the final stage of my project, I made a general version of the model so other cafeterias could map their entrances, exits, and serving stations. What began as a class assignment ended with changes I could actually see on campus, and I felt glad that something I learned could help the people around me.